DEV Community: Laura Bolaños

Una novedad en Serverless bajo la lupa: AWS Lambda Web Functions

Laura Bolaños — Fri, 16 Oct 2026 19:52:02 +0000

Introducción

AWS anunció Lambda Web Functions, una forma de ejecutar aplicaciones web y APIs sobre Lambda ejecutando directamente un servidor HTTP de Node.js, sin adaptadores ni handlers por evento. Aquí te describo mi propio análisis.
Este artículo no pretende ser una guía de cómo usar Lambda Web Functions. Hago un recorrido corto por las características que importan, referencio blogs de colegas y muestro mi propio enfoque de cuándo utilizarla y cuando No.
Para no quedarme en la teoría, armé un pequeño playground con ejemplos: desde un agente de IA con streaming hasta microservicios simulando alto tráfico. Además, hice algunos experimentos de concurrencia y comportamiento de escalado.

Qué es una Lambda Web Function

Una Lambda Web Function es cómputo serverless que corre un servidor HTTP normal. Tu aplicación escucha en el host y puerto que Lambda te pasa en la variable AWS_LAMBDA_HTTP_ENDPOINT, exactamente el mismo código que correrías con node index.js en tu máquina. AWS te da el endpoint HTTPS, el TLS y el escalado; de tu parte toca escribir Express (o el framework que uses) sin adaptadores.

NO es un reemplazo universal de la Lambda de siempre que devuelve un event handler. Esta sigue siendo la opción natural para lo que es dirigido por eventos: procesar mensajes de una SQS, reaccionar a un evento de S3, consumir un stream. Tampoco es un servidor que tengas "siempre encendido": escala a cero cuando no hay tráfico. Y por ahora solo soporta runtime Node.js.

Lo que cambia de verdad

Muchos de los protocolos que vas a ver en las demos (REST, SSE, streaming, webhooks) ya se podían hacer antes de otra forma. Lo que cambia no son los protocolos, sino la forma de la Lambda:

Modelo de programación. Antes escribías un handler que recibía un evento; ahora escribís un servidor HTTP común que escucha en un puerto.
Concurrencia. En una Event Function, cada entorno atiende una petición a la vez. En una Web Function, un mismo entorno atiende varias en simultáneo, como un servidor Node común. Para algo que pasa casi todo el tiempo esperando (una base de datos, una API, un LLM), eso significa que muchas peticiones comparten un proceso en lugar de ocupar un entorno cada una.
Parámetros importantes

Parámetro	descripción
`maxConcurrencyPerEnvironment`	tope por entorno, 1–128, se configura en la revisión. El límite real puede ser menor, nunca mayor. Cambiarlo crea una nueva revisión
`maxEnvironments`	tope de entornos por región, se configura en el endpoint.
`rateLimit`	peticiones por segundo que acepta el endpoint, por región. Lo que supera rateLimit recibe 429. Lo mismo ocurre si no puede escalar más, pero mientras un entorno nuevo se inicializa, las requests esperan en cola. rateLimit se aplica por región, y sus valores deben ser múltiplos de 100 (hasta 1.000) o de 1.000 (por encima).
`maxEnvironments` y `rateLimit`	se cambian en caliente con `aws lambda-web update-web-function-endpoint`, sin redeployar; en cambio `maxConcurrencyPerEnvironment` sí obliga a hacer una nueva revisión de la Lambda.

Entrada y salida: HTTP crudo, no un payload. Una Event Function recibe un event (un JSON ya parseado) y devuelve otro JSON; nunca tocás HTTP a mano. Una Web Function recibe y devuelve HTTP/1.1 crudo: Lambda reenvía a tu app el método, el path, la query string, el body y casi todos los headers, y tu servidor (Express, Fastify, Hono o el framework de Node que prefieras) ve un Request/Response normal. Soporta GET, HEAD, POST, PUT, PATCH, OPTIONS y DELETE, solo HTTP/1.1 (un HTTP/1.0 lo rechaza con 505), y agrega headers de contexto como lambda-web-request-id. Es justo lo que te deja usar tu framework sin adaptador, pero el parseo y la validación del request quedan de tu lado.
Seguridad: el endpoint es público, el modo de auth define quién valida. Todo endpoint es alcanzable desde internet, tenga el auth que tenga. Hay dos modos: con IamAuth, Lambda valida la firma SigV4 y remueve el header Authorization antes de reenviar (la autorización la hace la plataforma); con ApplicationManaged, Lambda no auténtica nada y reenvía todo a tu app, así que conocer la URL alcanza para llegar y es necesario implementar la autenticación. Sumá a eso que algunos headers no son de fiar (X-Forwarded-Host llega sin validar; el cliente real está en el último valor de X-Forwarded-For) y que validar input, tamaño de request y abuso es responsabilidad de tu código o de un front door.
Facturación: Pagás CPU activa y memoria mientras el entorno exista. No se cobra tiempo de reloj. Una petición que espera a una base de datos o a una API externa consume poca CPU, y esa espera casi no se cobra.
Proceso de larga vida. El entorno no se congela entre peticiones → hay estado global, conexiones reutilizadas y tareas en segundo plano.

⭐ Para el detalle de cada protocolo, el recorrido de edjgeek lo cubre muy bien, y el repositorio de ejemplos que acompaña ese blog muestra REST, SSE, NDJSON y webhooks funcionando.

Dónde NO lo usaría

Hay varios escenarios donde esta tipo de Lambda no aplica:

Request/response simple y de bajo volumen. Un formulario que dispara un mail, o una Lambda que devuelve un JSON corto cada tanto. Ahí una Event Function con su function URL es más simple y suficiente; migrar no te da ningún beneficio.
Trabajo dirigido por eventos. Procesar una cola SQS, reaccionar a un archivo en S3, consumir un stream. Eso es territorio de las Event Functions, y la propia documentación lo recomienda así.
Tareas largas. El timeout de una petición llega hasta 900 s (15 min). Si tu proceso puede tardar más, no entra en una sola petición: hay que partirlo o usar otro mecanismo.
WebSockets o HTTP/2. no mantiene conexiones bidireccionales persistentes de tipo TCP Upgrade abiertas directamente hacia el entorno de ejecución de la Lambda de forma continua. Si este es tu caso no se resuelve por aquí.
En Tareas multi-paso elegimos Lambda durable functions. Pensadas para flujos de trabajo resilientes de varios pasos que pueden durar hasta un año, con checkpoints, reintentos y estados de espera que no consumen cómputo mientras aguardan. Casos de uso: procesar pagos, orquestar pedidos, flujos con aprobación humana o workflows de IA de varios pasos.

⭐ La regla práctica: si tu carga no es "un servidor HTTP que atiende tráfico concurrente", probablemente Lambda Web Functions no corresponda a tu caso de uso.

¿Reemplaza a API Gateway / function URLs?

Una Web Function ya trae su propio endpoint HTTPS. Pero reemplaza en los casos simples, no es un reemplazo directo.

Pensemos primero en las function URLs, la URL pública de una Lambda común. Desde el lado del cliente, para un request/response sencillo, casi no hay diferencia: hacés una petición HTTP y recibís una respuesta. Si lo que tenés es una Lambda con su URL devolviendo un JSON corto, migrar a Web Functions no te cambia nada visible. Donde empieza a tener sentido es cuando aparece concurrencia con mucha espera, streaming, o una app con framework y varias rutas.

Con API Gateway la cuestión es diferente, porque son de distinta naturaleza: una Web Function es cómputo con un endpoint incluido, y API Gateway es una puerta de entrada que se pone delante del cómputo.

Si tenés una app con su propio router (Express, Hono, Fastify), antes necesitabas API Gateway para exponerla; ahora el endpoint ya viene con HTTPS, autenticación y un límite global de peticiones. Para APIs internas o servicios entre equipos, eso suele alcanzar.

Pero API Gateway sigue teniendo sentido como front door. La propia documentación de buenas prácticas recomienda poner CloudFront o API Gateway delante del endpoint cuando necesitás dominio propio, inspección con WAF, caché o controles centralizados en el borde. Y hay features que API Gateway te da y la Web Function no: planes de uso y API keys por cliente, authorizers (JWT, Cognito), cuotas por consumidor. El límite de peticiones de la Web Function es un tope por endpoint y región, no por cliente.

⭐ Para una app o microservicio con su propio router, Lambda Web Functions te AHORRA una capa. Para una API pública con múltiples consumidores, cuotas y políticas en el borde, seguís necesitando API Gateway o CloudFront según el caso.

Casos de Uso del playground

Construí ejemplos sencillos que pueden servirte para llevar a la práctica rápidamente tus casos de uso.

📦 Aquí vas encontrar ejemplos con dos maneras de desplegar: manualmente por la CLi o via SAM : github.com/reinalau/lambda-web-functions-playground

Lambda Web Functions ya es compatible con IaC:
AWS CloudFormation ( "AWS::Lambda::WebFunction resource").
AWS CDK (L2 constructs available)
AWS SAM

Un agente strands harness con streaming

Es un agente de IA hecho con strands harness, que responde preguntas sobre el clima y ayuda a planificar viajes. Recibe un mensaje, llama a herramientas que consultan una API pública (Open-Meteo), razona sobre los datos y devuelve la respuesta al navegador token a token por SSE. Mantiene la conversación entre turnos, recuerda lo que ya le dijiste.

%%{init: {"theme": "base", "themeVariables": {"fontSize": "30px"}}}%%
flowchart LR
    Client["Client / browser"] -->|"POST /chat"| Agent["weather-agent<br />Lambda Web Function (Express)<br />Strands harness"]
    Agent -->|"SSE: stream tokens"| Client
    Agent -->|"InvokeModelWithResponseStream"| Bedrock["Amazon Bedrock<br />Nova 2 Lite"]
    Agent -->|"tools (no API key)"| OpenMeteo["Open-Meteo API<br />geocode + forecast"]
    Agent -->|"SessionManager<br />by conversationId"| S3[("Amazon S3<br />session state")]

    style Client fill:#2563eb,stroke:#1e40af,color:#ffffff
    style Agent fill:#f59e0b,stroke:#b45309,color:#ffffff
    style Bedrock fill:#15803d,stroke:#0f5027,color:#ffffff
    style OpenMeteo fill:#64748b,stroke:#475569,color:#ffffff
    style S3 fill:#4ade80,stroke:#16a34a,color:#063d1e

Por qué con Web Functions y no con otra cosa → Este caso pasa casi todo el tiempo esperando al modelo y a las herramientas, consumiendo muy poca CPU, y esa espera casi no se cobra. Además:

El modelo de servidor HTTP me deja usar el harness de Strands y Express tal cual, sin reescribir nada como handler ni armar un adaptador.
El streaming de tokens por SSE es nativo: devuelvo la respuesta a medida que se genera, sin esperar a tenerla completa.
La concurrencia por entorno significa que muchas conversaciones conviven en el mismo proceso mientras esperan al LLM, en vez de ocupar un entorno entero cada una (como pasaría con una Event Function).

En una Event Function con function URL pagaría el tiempo de reloj completo de cada conversación y ocuparía un entorno por request. Acá no.

La implementación: Es Express corriendo como Web Function. El agente usa el harness de Strands (TypeScript) con builtinTools: [] para dejar solo las dos herramientas de clima (nada de shell ni acceso a archivos: menor superficie), sobre un modelo Amazon Nova en Bedrock.

El punto fino es el estado: como el entorno es efímero y no hay afinidad de sesión, la conversación no puede vivir en memoria; se persiste fuera, en S3, usando el SessionManager del SDK. Cada conversación se identifica por un id, y cualquier entorno puede retomarla. El detalle completo lo encontrás en el README del ejemplo.

Un BFF con microservicios (pedidos + inventario)

Este ejemplo consta de dos Lambda Web Functions que modelan un patrón BFF + microservicios, sin IA: solo API y DynamoDB. Un servicio orders (el BFF, público) recibe un pedido, reserva stock llamando a un servicio inventory (privado) y persiste el pedido. inventory expone el stock y lo reserva con un UpdateItem condicional que nunca lo deja en negativo (devuelve 409 si no alcanza).

Este caso es de un "backend de alto tráfico que espera mucho I/O": cada pedido llama a otro servicio y a una base de datos, y pasa la mayor parte del tiempo esperando esas dos cosas.

%%{init: {"theme": "base", "themeVariables": {"fontSize": "28px"}}}%%
flowchart LR
    Client["Client"] -->|"POST /orders (no signing)"| Orders["orders BFF<br />Lambda Web Function<br />ApplicationManaged"]
    Orders -->|"SigV4-signed call<br />service: lambda<br />x-amz-content-sha256"| Inventory["inventory<br />Lambda Web Function<br />IamAuth (private)"]
    Orders -->|"PutItem"| OrdersDB[("DynamoDB<br />orders table")]
    Inventory -->|"conditional UpdateItem<br />reserve stock or 409"| InventoryDB[("DynamoDB<br />inventory table")]

    style Client fill:#22c55e,stroke:#15803d,color:#ffffff
    style Orders fill:#f59e0b,stroke:#b45309,color:#ffffff
    style Inventory fill:#f59e0b,stroke:#b45309,color:#ffffff
    style OrdersDB fill:#3b82f6,stroke:#1d4ed8,color:#ffffff
    style InventoryDB fill:#3b82f6,stroke:#1d4ed8,color:#ffffff

Algunas características:

El servidor HTTP deja usar Express con su router tal cual; orders enruta por dentro y no necesito una función por ruta ni API Gateway delante.
La concurrencia por entorno deja que muchas peticiones convivan en el mismo proceso mientras esperan a inventory y a DynamoDB.
Cada servicio escala por separado: un pico en el BFF no obliga a sobredimensionar el inventario.

Comunicación entre servicios con IamAuth. La mayoría de las reseñas lo pasa por alto: inventory es privado (IamAuth), así que orders no lo invoca con un SDK → tiene que firmar la petición HTTP con SigV4 usando el servicio lambda, e incluir siempre la cabecera x-amz-content-sha256 (Lambda la usa como hash del payload en vez de leer el body).

El rol de orders necesita el permiso lambda:InvokeWebFunctionEndpoint sobre el endpoint de inventory, y Lambda elimina la cabecera Authorization antes de reenviar la request a la aplicación. Para endpoints multi-región la firma pasa a SigV4a.

La implementación: Dos servicios Express en TypeScript, cada uno su propia Web Function con su rol de mínimo privilegio. inventory guarda el stock en DynamoDB y hace la reserva atómica; orders firma su llamada a inventory, y si la reserva sale bien persiste el pedido en otra tabla. El detalle (despliegue ordenado, IAM y la receta de firma) está en el README del ejemplo.
Hice dos experimentos de caga sobre el BFF. Los números salen de los eventos de CloudWatch (invokeReport / initReport).

Experimento 1 ➡ Carga: ¿cuánta CPU se cobra?

Objetivo: analizar con tráfico concurrente qué fracción del tiempo del entorno se factura como CPU. 500 pedidos, 50 en paralelo (no 500 a la vez: 500 en total).

Métrica	Valor
Pedidos (todos `201`)	500
Tiempo de reloj	15 s
Entornos creados	61
Pico de concurrencia por entorno	2
CPU activa de serving (toda la flota)	~49 s
CPU de arranque (toda la flota)	~22 s
Vida de servicio sumada	~24.461 s

Análisis: la CPU de serving (~49 s) es ~0,2% de la vida de servicio sumada (~24.461 s). Cuidado con la lectura: ese 99,8% restante no es todo "espera de I/O". La carga duró 15 s, pero cada entorno siguió vivo ~400 s hasta escalar a cero, así que la mayor parte es ocio del entorno después de la carga, no espera por request. El punto importante, ese tiempo no se cobra como CPU (la memoria sí se cobra mientras el entorno exista). Medir la espera de I/O por request requiere los eventos requestComplete (nivel DEBUG), que no lo activé acá.

⭐ Un detalle de la concurrencia: 50 pedidos en paralelo deberían caber en pocos entornos (uno atiende hasta 64), pero se abrieron 61 con un pico de solo 2 por entorno. No es un parámetro que faltó setear como maxConcurrencyPerEnvironment porque solo fija el techo. Por debajo, Lambda usa un límite dinámico por entorno que ajusta según el uso de recursos, y lo baja cuando cada request consume CPU (acá, la firma SigV4). Con poca concurrencia por entorno, Lambda abre más entornos, y cada uno paga su arranque: eso explica el costo del Experimento 2. La ventaja de "menos entornos por concurrencia compartida" frente a una Event Function es real, pero el reparto lo decide la plataforma, no tu config.

Experimento 2 ➡ ¿Cuánto cuesta un pedido?

Objetivo: separar el costo de arranque del trabajo real por pedido. Dos corridas: 1 pedido en un entorno frío, y 200 pedidos secuenciales en el mismo entorno caliente.

Corrida	Pedidos	CPU total
Entorno frío	1	~780 ms
Entorno caliente	200	~2.600 ms

Análisis: el costo marginal por pedido es (2.600 − 780) / 199 ≈ 9 ms. O sea, un pedido en caliente cuesta ~9 ms de CPU (SigV4 + JSON + la parte de CPU del I/O), pero el primer pedido de un entorno frío cuesta ~780 ms (arranque de Node + carga del SDK + primera conexión), unas 85 veces más. En una Web Function, lo que domina el costo de CPU es cuántos entornos se abren, no cuántos pedidos se atienden.

Conclusiones

Lambda Web Functions no viene a reemplazar a la Lambda de siempre, suma una forma más, junto a las Event Functions y las durable functions. Su enfoque es claro: cargas que son, en esencia, un servidor HTTP atendiendo tráfico concurrente que pasa la mayor parte del tiempo esperando I/O. Ahí el modelo encaja muy bien.

Las ventajas que comprobé en el playground

Código de servidor común (Express) sin adaptadores, que corre igual en local y en AWS.
Concurrencia por entorno: cada entorno atiende varias peticiones mientras esperan I/O.
Facturación por CPU activa: en la prueba del BFF, la CPU de serving fue ~0,2% de la vida de los entornos; la espera de I/O casi no se cobra.
Streaming nativo (el SSE del agente) sin configuración extra.
Controles en el endpoint (rateLimit, maxEnvironments) para proteger a las dependencias que están detrás, como una base de datos.
Comunicación privada entre servicios con IamAuth, aunque exige firmar las peticiones a mano con SigV4.

Sobre migrar

Si ya tenés una app Express o Hono corriendo en Lambda con un adaptador, la migración es mayormente quitar el adaptador y escuchar en AWS_LAMBDA_HTTP_ENDPOINT. Si viene de handlers por evento, hay que reescribirla como servidor. En los dos casos no conviene cambiar todo de golpe: las revisiones y los pesos por revisión del endpoint permiten hacer un canary (mandar un porcentaje del tráfico a la versión nueva y volver atrás si algo falla), que es lo que recomienda la guía de buenas prácticas para producción. Y antes de migrar, conviene preguntarse si hay algo para ganar: un endpoint de bajo volumen con request/response simple no mejora.

Un punto importante, aunque lo nombre muchas veces en estas notas, es que hoy solo ofrece runtime con node.js.

Medir antes de decidir

Los números del playground salen de una simulación. Sirven para entender el modelo, no para cotizar. La documentación recomienda hacer pruebas de carga con las mismas dependencias que en producción, subiendo la concurrencia hasta ver qué se agota primero (latencia, CPU, memoria o la base de datos), y revisar antes las cuotas de la cuenta y de la región. Con esos resultados se ajustan maxConcurrencyPerEnvironment, maxEnvironments y rateLimit. El costo real hay que verlo en la factura: la memoria se cobra durante toda la vida del entorno, y lo que más mueve la CPU no es el trabajo por pedido (~9 ms en caliente en el BFF) sino cuántos entornos se abren, porque cada uno paga su arranque (~780 ms el primer pedido de un entorno frío).

Lecciones aprendidas

La plataforma importa tu módulo a través de un wrapper, no lo ejecuta como entrypoint: el servidor tiene que arrancar al importarse.
/ping está reservado por la plataforma; para el health check hay que usar otra ruta.
Toda dependencia que use el código, incluido el AWS SDK, tiene que estar declarada en el package.json; si no, falla recién en runtime.
No hay afinidad de sesión y el entorno puede desaparecer en cualquier momento: el estado va afuera (S3, DynamoDB).
Los log groups se crean sin expiración; conviene fijar la retención.
Con SAM, CodeUri tiene que ser un objeto en un bucket S3 versionado: sam build no empaqueta código local para este recurso.
Es un servicio nuevo: hacen falta versiones recientes del AWS CLI y de SAM CLI.

Referencias

Sumergiéndonos en Strands Agents Harness 🐬

Laura Bolaños — Sat, 10 Oct 2026 19:36:27 +0000

Un recorrido práctico por Strands Agents Harness, la forma de crear agentes óptimos y listos para producción en una sola llamada. Según sus benchmarks, logra rendimiento de vanguardia con un coste de token un 28 % menor. Pero ¿qué pasa cuando lo sacás del ejemplo de la doc y lo ponés a trabajar en un caso más real? 🧐

Introducción

Hoy, por todos lados, nos enseñan a crear un agente en dos líneas. Y es cierto: con Strands harness, create_harness() te devuelve un agente que ya trae shell, herramientas de archivo, acceso web, memoria y sesiones. Con una pequeña tarea funciona e impresiona.

Pero cuando dejás el ejemplo de demo y te ponés a construir algo real, aparece todo lo que esas dos líneas tapan. Un agente no es una llamada y una respuesta: es un proceso que corre por turnos, que decide por su cuenta cuántas veces usar sus herramientas antes de contestar, que recuerda conversaciones previas si le das una sesión, que arrastra un contexto que crece y hay que administrar, y que puede tener memoria de largo plazo que a veces ayuda y a veces estorba. Entender cómo encajan turnos, sesiones, memoria, contexto es la diferencia entre un demo y un prototipo que se sostiene.

Descubrí que el harness empareja las condiciones, pero se comporta diferente según el modelo. Algunos de estos hallazgos los plasmo en estas notas.

Conceptos clave de Strands harness

Strands harness es un harness de agente ya ensamblado: con una sola llamada (create_harness() en Python, createHarness() en TypeScript) obtenés un agente listo para trabajar, sin tener que cablear las piezas. Está construido sobre el Strands Harness SDK, y lo que te devuelve es un strands.Agent estándar optimizado: no hay wrapper ni abstracción oculta, así que cualquier default se puede sobreescribir, extender o reemplazar.

La idea de fondo: en vez de armar un agente pieza por pieza (modelo, herramientas, memoria, sesiones, gestión de contexto, system prompt), arrancás desde un agente ya optimizado y solo ajustás lo que tu caso de uso necesita.

Es diferente a Strands Harness SDK que es la capa de mas bajo nivel. El SDK te da las piezas sueltas (herramientas, proveedores de modelos, memoria, sesiones, hooks) y armás el agente desde cero: elegís cada componente, cómo se relacionan y controlás el ciclo de vida completo. El harness, en cambio, ya tiene ensambladas todas esas piezas.

Tres formas de comenzar a crear tu Agente.

Configurar el harness mediante la CLI

Esta opción te permite generar el agente y testearlo → prototipar rápido. Aún le falta madurar, a la fecha de la prueba algunas opciones me las deja como no elegidas en el harness cuando intentaba exportar el agente, pero seguramente lo vayan puliendo pronto. Te invito a experimentar.

Básicamente instalás la CLI (en mi caso para Python)

npm install -g @strands-agents/cli

En tu terminal iniciás la CLI con la palabra strands, te abrirá una interfaz similar. Aquí podés customizar el harness, activando o desactivando lo que desees, indicarle nombre-system prompt, etc. Si tenés modelos locales vía Ollama te los detecta (los podés setear), si tenés en tu máquina configurada credenciales de AWS te permite elegir cualquier modelo soportado por Bedrock y por supuesto configurar el modelo vía API key:

Luego podés probar el agente en el chat de la CLI o acceder a cualquier settings con / (notar que aquí tengo seleccionado "Nova 2 Lite"):

Podés ver este video que hace un tour por la CLI.

Configurar el harness mediante tu agente de Código (kiro, claudecode, codex...)

Esta opción básicamente es un prompt predefinido que copiás/pegás. Lo probé con Kiro y te guía para crear el harness sin importar el caso de uso. Conviene en la primera interacción indicarle tu listado de requerimientos para el agent harness y subagentes que quieras crear + el prompt predefinido.

Siempre es útil, si vas a empezar a crear agentes con Strands Agents Harness, que configures el MCP server de Strands en tu agente de código. Le da acceso en vivo a la documentación oficial, así genera código con las últimas versiones y tu asistente no lo saca de su conocimiento. Necesita uv instalado y se ejecuta con uvx strands-agents-mcp-server. En Kiro, se agrega en ~/.kiro/settings/mcp.json:

{
  "mcpServers": {
    "strands-agents": {
      "command": "uvx",
      "args": ["strands-agents-mcp-server@latest"],
      "disabled": false
    }
  }
}

Para otros agentes de código (Cursor, Claude Code, Codex, VS Code) la idea es la misma; cambia la ubicación del archivo de configuración.

Usalo como una librería (library)

pip install strands-harness

Y comenzás a escribir tu harness:

from strands_harness import create_harness

agent = create_harness()
agent("Research the three most common strategies for versioning a REST API, compare their tradeoffs, and write a recommendation to api-versioning.md")

Qué trae el agente por defecto

Sin pasar ningún argumento, create_harness() ya te entrega un agente que:

Corre sobre el modelo que elijas, con proveedores: Amazon Bedrock (default), Anthropic, OpenAI, Google y Ollama (local). Con razonamiento activado por defecto.
Sigue un system prompt afinado: explorar antes de actuar, confirmar antes de algo irreversible, y verificar antes de dar una tarea por terminada.
Trae herramientas listas:
- Un shell (shell virtual pensado para agentes). Aquí hay que tener cuidado: ¡es peligroso dejarlo activado si no lo vas a usar!
- Herramientas de archivo: read, write, edit.
- Acceso web: web_fetch (siempre activo) y web_search (según el proveedor).
- programmatic_tool_caller: un sandbox donde el agente escribe código que encadena, repite y paraleliza sus otras herramientas para orquestaciones más complejas.
Gestiona su propia ventana de contexto: resume turnos viejos y mueve resultados voluminosos a almacenamiento, dejando una referencia corta para recuperarlos. Cachea las partes reutilizadas de cada request donde el proveedor lo soporta.
Recuerda: cada conversación se guarda en disco y es reanudable por session id; además tiene memoria de largo plazo que destila hechos entre conversaciones.
Delega subtareas a un subagente integrado (lo explico más adelante).
Carga Agent Skills cuando están presentes: podés reutilizar las existentes y también crear nuevas.

El modelo por defecto es un modelo de frontera (Claude Opus en Bedrock). Esto es importante: el harness está afinado para modelos frontera, y eso explica varias de las limitaciones que aparecen con modelos más chicos.

Cómo se ejecuta un agente: el agent-loop y los turnos

Un detalle que conviene tener claro desde el principio: cuando le das una tarea al agente, no hace una sola llamada al modelo y responde. Entra en un bucle (el agent-loop): el modelo piensa, decide usar una herramienta, recibe el resultado, vuelve a pensar, usa otra herramienta, y así hasta que considera que terminó. Una sola petición tuya puede disparar varias idas y vueltas al modelo. Esto es lo normal y lo deseable, es lo que le permite leer un archivo, razonar sobre él y después escribir. Pero también significa que un "turno" puede costar varias llamadas (y en modelos con cuota limitada, eso se nota).

Cada agente corre su propio agent-loop, incluidos los subagentes. Un subagente sin herramientas suele resolver en una sola iteración; el agente principal, que lee, delega y escribe, hace el bucle largo.

Sesiones, memoria y contexto: lo que el agente arrastra entre turnos

Tres piezas distintas que es fácil confundir:

Sesión: el historial de la conversación. El harness lo persiste en disco y lo puede reanudar si le das un session id estable. Es la "memoria de corto plazo" de esta historia.
Memoria de largo plazo: hechos que el agente destila entre conversaciones (preferencias, datos del proyecto), guardados aparte. Útil para que recuerde cosas entre sesiones distintas; prescindible y a veces contraproducente, si tu estado ya vive en archivos propios.
Contexto (la ventana del modelo): el texto que el modelo lee de una sola vez. Crece con cada turno, así que el harness lo administra: resume lo viejo y mueve resultados grandes a almacenamiento, dejando una referencia para recuperarlos.

Entender estas tres capas es lo que separa un demo de un prototipo que se sostiene entre ejecuciones.

La interfaz `create_harness(...)` y cómo podemos acceder

Todos los argumentos son opcionales. Los más relevantes para empezar:

Argumento	Para qué sirve
`model`	`"proveedor/nombre"`, un id de Bedrock a secas, o una instancia `Model`.
`effort`	Nivel de razonamiento: `auto`, `off`, `minimal`, `low`, `medium`, `high`, `xhigh`, `max`.
`instructions`	Texto de dominio que se añade al system prompt (identidad, reglas, alcance).
`tools`	Tus herramientas propias, junto a las integradas.
`builtin_tools`	Edita el set de herramientas integradas (una lista fija los nombres; un mapa agrega/quita/configura).
`session`	`True` \
`memory`	Memoria de largo plazo: `True`, un dict de config, o `False`.
`caching`	Cachea system prompt, tools e historial donde se soporta.
`mcp_servers`	Conecta servidores MCP (ruta a un JSON o el mapping inline).
`interventions`	Puertas de aprobación sobre las llamadas a herramientas.

Ejemplo de cómo elegir modelo:

create_harness(model="anthropic/claude-opus-5")              # Anthropic directo
create_harness(model="openai/gpt-5.6-sol")                   # OpenAI
create_harness(model="google/gemini-2.5-flash")              # Google
create_harness(model="bedrock/global.anthropic.claude-opus-5")  # el default, explícito

Cada proveedor necesita su extra: pip install "strands-harness[gemini]" (o [anthropic], [openai], [ollama], [litellm]). Bedrock viene de base.

Observar logs del modelo y Evaluar el agente (evals)

Si usás algún modelo vía Amazon Bedrock, podés activar los logs en la consola de AWS y revisar cómo se está invocando tu modelo y cómo resuelve las instrucciones incrustadas por el harness:

Un agente que "parece que anda" no es un agente que anda. Antes de confiar en él conviene evaluarlo: ¿elige bien las herramientas?, ¿sigue las instrucciones?, ¿comunica los fallos en vez de inventar que todo salió bien? Strands incluye un SDK de evaluaciones (/evals) justamente para esto —validar el comportamiento del agente antes de darlo por bueno— con evaluadores de calidad, de seguimiento de instrucciones, de selección de herramientas y más.

Primeras pruebas: lo que la documentación no te cuenta

Esta es la parte más valiosa del artículo: lo que la doc no te cuenta y aparece al ejecutarlo de verdad en Windows con modelos chicos. La tarea de prueba era sencilla: investigar estrategias de versionado de una REST API y escribir una recomendación en un .md.

Antes de entrar en los tropiezos, conviene recordar algo que la propia doc deja claro: el harness está optimizado para modelos grandes o de frontera (su default es Claude Opus en Bedrock). Su system prompt afinado (el que está en el harness, no el que le incrustamos nosotros), el agent-loop, la gestión de contexto y el uso de herramientas asumen un modelo con buena capacidad de razonamiento y de seguimiento de instrucciones. Con un modelo chico el harness igual arranca, pero empiezan las fricciones: el modelo se enreda con las herramientas, inventa rutas, no sabe cerrar la tarea. No son bugs del harness en sí; es el desajuste entre un andamiaje pensado para modelos capaces y un modelo que no llega. Es importante que lo tengas presente.

Nova-2-lite (Amazon Bedrock)

Bucle de web_fetch: global.amazon.nova-2-lite-v1:0 no tiene web_search nativo. Sin búsqueda real, el agente intentó "investigar" trayendo página tras página con web_fetch: llegó a 229 llamadas seguidas sin cerrar la tarea. Se arregla dándole búsqueda de verdad con builtin_tools={"web_search": "exa"} y/o acotando la tarea.
Rutas de Windows "unixificadas": la herramienta write exige ruta absoluta. Nova-2-lite convertía la ruta C:\Users\... a formato Unix /C/Users/..., así que escribía al vacío. El archivo nunca aparecía donde debía. El modelo razona como si estuviera en Linux.
No reporta bien los errores: afirmaba "escribí el archivo" cuando no era cierto. Lección: verificar en disco, no confiar en lo que el agente dice.

Gemini (Google)

Cambiar a Gemini resolvió lo de las rutas, pero trajo límites propios del proveedor:

Cuota de la capa gratuita (429 RESOURCE_EXHAUSTED): el harness hace muchas llamadas por minuto (razonar, buscar, procesar, escribir) y supera el límite RPM gratuito enseguida. Una llamada simple de prueba sí funcionaba; la ráfaga del harness no.
No se puede combinar búsqueda nativa + function calling (400 INVALID_ARGUMENT): Gemini rechaza usar google_search junto con el resto de herramientas en la misma petición. Solución: builtin_tools={"web_search": False}.
"Thinking level is not supported" (400): el harness activa razonamiento por defecto (effort="auto"), y gemini-2.5-flash rechazó el nivel que le llegaba. Solución: effort="off". Probé también low y medium y los rechazó igual: con este modelo, apagar el razonamiento fue la única salida.
A veces no llama a write: con el razonamiento apagado, el modelo pequeño respondía el texto en el chat en lugar de invocar la herramienta de escritura.

Algunas soluciones que podés adoptar

Después de varias iteraciones, la conclusión fue: confiar en que un modelo pequeño invoque write con la ruta correcta es frágil. La herramienta write funciona; lo que falla es que el modelo chico la use bien.

Patrón robusto: dejar que el agente genere el contenido y que Python escriba el archivo con str(result). Así se saca de la ecuación la parte que falla (que el modelo construya bien la ruta de Windows) y se garantiza el resultado. Ejemplo:

result = agent("...devuelve solo el documento markdown...")
with open(ruta_absoluta, "w", encoding="utf-8") as f:
    f.write(str(result))

Inconvenientes con Unicode en consola (Windows)

Comenté algunos tropiezos que tuve pero vale la pena mencionar por si recién estás empezando en este mundo. En Windows la consola usa cp1252 y crashea al imprimir emojis (p. ej. el ✅ que el agente pone al confirmar). Eso tiraba el proceso con UnicodeEncodeError antes de terminar. Se arregla forzando UTF-8 al inicio del script:

import sys
sys.stdout.reconfigure(encoding="utf-8", errors="replace")
sys.stderr.reconfigure(encoding="utf-8", errors="replace")

Sesiones: mantener una conversación entre ejecuciones

Por defecto el harness persiste cada conversación en disco bajo ./.agent/sessions. Pero no reanuda solo: sin id, genera uno nuevo en cada corrida (por eso aparecen carpetas con nombres aleatorios). Para continuar una conversación, hay que pasar un id estable:

agent = create_harness(session={"id": "api-design"})
agent("¿Dónde quedamos?")

Un ejemplo en dos ejecuciones separadas (dos corridas del programa, una después de la otra, cerrando la primera antes de abrir la segunda):

Primera corrida: se construye el agente con session={"id": "api-design"} y se le pide, por ejemplo, que compare tres estrategias de versionado de una API. Se cierra el programa.
Segunda corrida: se vuelve a construir el agente con el mismo id ("api-design") y se le pregunta "¿cuál de esas elegirías...?". Aunque es un proceso nuevo, el agente responde correctamente sin que le repitas cuáles eran las opciones: recuerda la conversación anterior.

Eso funciona porque el estado quedó guardado en ./.agent/sessions/session/api-design/ como snapshot_latest.json, y el harness lo rehidrata al construir un agente con ese mismo id. Si no pasás un id, cada corrida genera uno nuevo y arranca de cero.

session={"dir": ...} cambia dónde vive el estado.
session=False desactiva la persistencia (corrida desechable).
Para multi-host, se pasa un SessionManager propio (por ejemplo S3SessionManager).

Esto último merece una aclaración, es clave si pensás llevar el agente a producción. Por defecto el harness guarda las sesiones en el disco local de la máquina donde ejecuta. Eso alcanza mientras ejecutes siempre en el mismo lugar. Pero cuando el agente vive en varias máquinas a la vez o en funciones serverless (que se levantan y apagan), el disco local deja de servir. La solución es guardar las sesiones en un lugar compartido por todas las máquinas, y para eso se usa S3SessionManager, que guarda el estado en Amazon S3.

from strands.session.s3_session_manager import S3SessionManager
create_harness(session=S3SessionManager(session_id="api-design", bucket="mi-bucket"))

Dato para tener en cuenta: si desplegás en Amazon Bedrock AgentCore Runtime, las sesiones guardadas en disco se pierden cuando la microVM se reinicia. Ahí es donde podemos usar S3 para no perder el estado.

Un caso de uso completo: Narrador de Historias

Armé un narrador de historias (aún en construcción), inspirado en Sherpa de Pocket FM pero reducido a lo esencial, solo texto, en español, sin audio ni imágenes. Invocás al agente y te entrevista qué clase de historia querés escribir (formato, género, tono, personajes, premisa) y se pone a trabajar.

No es un solo agente respondiendo, sino un conjunto de agentes trabajando como un pequeño taller literario. Un orquestador (el narrador) conduce la conversación y escribe la prosa, y delega el trabajo de revisión en tres subagentes especialistas, uno que chequea la continuidad contra la "biblia" de la historia, otro que audita la estructura y el ritmo, y un bibliotecario que mantiene esa biblia actualizada. Cada uno hace su parte sin ensuciar el contexto principal.

📦 GitHub: github.com/reinalau/strands-harness-narrador

La arquitectura: un orquestador y tres subagentes

Subagentes trabajando para un orquestador

Un subagente es un agente al que el agente principal puede llamar como si fuera una herramienta. Lo importante es que la subtarea corre en su propia conversación fresca y solo vuelve su respuesta final — el trabajo intermedio no inunda el contexto principal. Hay dos formas de usarlos, y conviven.

El generalista integrado (built-in). El harness activa por defecto un subagente llamado generalist, expuesto al agente como herramienta. Es un agente harness completo que hereda la configuración del padre (modelo, razonamiento, caching, gestión de contexto, herramientas integradas, plugins, subagentes, interventions y sandbox), pero corre con un prompt de rol genérico en lugar de tus instructions (es el prompt que hace a la identidad del agente, no le decimos system prompt porque el harness lo compone: contrato del harness + tus instructions). Arranca de una conversación en blanco, así que el modelo debe meter en la llamada todo lo que la subtarea necesita, y devuelve una única respuesta autocontenida. No hay que crearlo, viene activado y corre en segundo plano. Se usa cuando una subtarea inundaría el contexto principal (buscar entre muchos archivos, un cambio multi-paso, exploración abierta donde solo necesitás la conclusión). Para desactivarlo:

agent = create_harness(builtin_tools={"subagent": False})  # sin generalista

En el narrador el generalista no se usa: al configurar builtin_tools={"*": False, "read": True, "write": True, "edit": True} partimos de cero y solo habilitamos las herramientas que nombramos, así que el subagent integrado queda apagado. La delegación la hacen los tres especialistas de abajo.

Agentes especialistas (Agents as Tools). En este caso de uso creé agentes especialistas: se pasan instancias de Agent envueltas con as_tool() (Python) / asTool() (TS). Cada uno se convierte en una herramienta nombrada según el name del agente, así que conviene darle un name y description claros para que el modelo sepa cuándo usarla.
Ejemplo:

from strands import Agent
from strands_harness import create_harness

researcher = Agent(
    name="researcher",
    description="Investiga un tema y devuelve un resumen conciso y con fuentes.",
    system_prompt="Investiga el tema dado y devuelve un resumen conciso y con fuentes.",
)

agent = create_harness(tools=[researcher.as_tool()])

Cada llamada corre desde el estado base del especialista (conversación fresca), así que no acumula estado entre llamadas. El name del subagente debe ser único en el set de herramientas, igual que cualquier tool.

En el narrador, los tres revisores (continuidad, estructura/ritmo, bibliotecario) son especialistas de este tipo: trabajan sobre el capítulo sin ensuciar la conversación principal, y solo devuelven su reporte o su JSON.

Ojo con el modelo: `Agent` crudo necesita una instancia de modelo

Acá me comí un error que vale la pena contar, porque es fácil de cometer. Al orquestador lo creás con create_harness(model="google/gemini-3.5-flash"), y ese string con prefijo —"google/...", "bedrock/..."— funciona porque lo resuelve el harness: traduce el atajo a una instancia de modelo del proveedor.

Pero los subagentes especialistas son Agent crudos del SDK, no harness. Y si a un Agent crudo le pasás ese mismo string, falla:

ValidationException ... The provided model identifier is invalid.

El Agent del SDK no entiende el prefijo "google/...": lo interpreta como un id de Bedrock a secas y revienta. La solución es pasarle una instancia de modelo del SDK, no el string:

from strands import Agent
from strands.models.bedrock import BedrockModel

continuidad = Agent(
    name="continuidad",
    description="Revisa la continuidad de un capítulo contra la biblia.",
    system_prompt="Sos un revisor de continuidad...",
    model=BedrockModel(model_id="us.amazon.nova-lite-v1:0", region_name="us-east-1"),
)

Regla para recordar: el string "proveedor/nombre" es syntactic sugar del harness (un atajo de sintaxis que resuelve solo create_harness()); fuera de él (en un Agent del SDK) tenés que instanciar el modelo vos mismo con GeminiModel(...), BedrockModel(...), etc.

La biblia con structured output

La "biblia" de la historia (personajes, relaciones, qué sabe cada uno, hilos abiertos, objetos, línea de tiempo) vive en bible.json, y la mantiene el subagente bibliotecario. El primer impulso es pedirle al modelo "devolveme el JSON actualizado, sin

``" y después parsearlo. Funciona a veces: un modelo chico mete un backtick de más, un comentario, una coma colgada, y eljson.loads` explota.

El harness (vía el SDK) tiene una forma mejor: structured output. Definís el esquema con un modelo Pydantic y se lo pasás a la invocación; el SDK se encarga de que la respuesta salga validada contra ese esquema. En lugar de esperar con incertidumbre, obtenés un objeto que ya cumple la forma esperada.

En el narrador, la biblia es un modelo Pydantic (Biblia, con submodelos para personajes, relaciones, etc.), y el bibliotecario se invoca pidiéndole esa forma:


python
from pydantic import BaseModel

class Biblia(BaseModel):
    meta: Meta
    personajes: list[Personaje]
    relaciones: list[Relacion]
    # ... hilos_abiertos, objetos, linea_de_tiempo

# dentro de la tool del bibliotecario:
result = _bibliotecario_agent(prompt, structured_output_model=Biblia)
biblia: Biblia = result.structured_output        # objeto validado, no texto suelto
return biblia.model_dump_json(indent=2)           # el orquestador lo escribe en disco

El valor validado se lee en result.structured_output. Después lo serializo con model_dump_json() y es el orquestador quien lo escribe en bible.json, el bibliotecario solo genera y valida, nunca toca disco. Así la biblia siempre tiene la forma correcta, sin importar lo prolijo que sea el modelo que la generó.

Human-in-the-loop: un capítulo por turno

Cuando pensé en que intervenga una persona con el agente, mi primer reflejo fue buscar un mecanismo del harness: interventions, que gatea las llamadas a herramientas y pide aprobación antes de ejecutarlas. Pero eso resuelve otra cosa (aprobar o no una acción riesgosa), no lo que yo quería. Lo que buscaba era más simple: que el narrador escriba un capítulo, lo guarde, y pare, que no siga de largo con el capítulo 2, para que yo pueda leerlo, editarlo, y recién entonces decirle cómo seguir.

Y esa pausa no necesita ningún mecanismo especial: es el chat por turnos. El agente termina su turno después de guardar el capítulo, y el control vuelve a mí. La regla la fijé en el system prompt: escribí un capítulo por turno; después de guardarlo, pará y esperá a que te pidan "revisar" o "continuar"; no empieces el siguiente por tu cuenta.

La pieza que hace que esto sea sólido es que los archivos son la fuente de verdad. Si yo edito a mano story/capitulo-01.md o bible.json entre turnos, el agente no se entera por arte de magia: tiene que releer desde disco antes de actuar. Así que el prompt también le ordena que, al pedirle "revisar" o "continuar", vuelva a leer los archivos en vez de confiar en lo que tiene en su contexto (que puede estar desactualizado respecto a mis ediciones). El flujo es así:

Le pido un capítulo → lo escribe, lo guarda, y para.
Lo leo. Si quiero, edito el .md o la biblia a mano.
Le digo "revisá" → relee desde disco, delega en continuidad y estructura, y me reporta.
Le digo "continuá" → relee la biblia y el último capítulo, y escribe el siguiente.

Dos modelos, un mismo harness: cada uno con su personalidad

El diseño terminó con dos modelos: el orquestador (que escribe la prosa y en disco) y los subagentes de análisis (que no tocan disco, así que pueden correr en un modelo más barato). Pero llegar a esa repartición no fue elegir en un papel, fue probar modelo tras modelo.

El recorrido para el orquestador fue así:

Nova 2 Lite (Bedrock): barato y disponible, pero en Windows inventa rutas estilo Linux (/C/..., /workspace/...). La herramienta write exige ruta absoluta y el modelo construye una que no existe, así que el archivo nunca se graba. Encima afirmaba haber guardado cuando no era cierto.
Gemini 2.5 Flash (Google): resolvió las rutas, pero trajo lo suyo. Rechazó el nivel de razonamiento que el harness activa por defecto (Thinking level is not supported, hay que forzar effort="off"), no deja combinar su búsqueda nativa con el resto de herramientas.
Nova Pro (Bedrock): más capaz, probé si manejaba mejor la escritura. Dos sorpresas: primero un ValidationException: User messages cannot contain reasoning content (el harness le mandaba bloques de reasoning que el modelo rechaza); y cuando logró escribir, también unixificó la ruta (/workspace/prueba2.md), confirmado leyendo el log de invocación en CloudWatch. Mismo problema de rutas que su hermano chico.
Gemini 3.5 Flash (Google): el que mejor se portó —construye rutas correctas y escribe donde debe.

Por eso terminó teniendo sentido la repartición en dos modelos: dejar la escritura y la prosa en manos de un modelo que se porta bien con el sistema de archivos, y mandar el análisis (que solo lee y devuelve texto, sin tocar rutas) a uno más barato y chico.

Qué queda por explorar

Para no estirar el artículo, dejé afuera varias piezas del harness que quedan para una próxima. Las menciono por si querés seguir el camino por tu cuenta:

Agent Skills: habilidades que el agente carga desde ./.agent/skills, con sus instrucciones y archivos de apoyo. Útil para empaquetar "cómo hacer X" sin inflar el system prompt.
Interventions: las puertas de aprobación del harness ("ask", "smart", políticas en lenguaje natural, Cedar). Las nombré al hablar del human-in-the-loop, pero no las usé en el narrador.
Gestión de contexto y caching en detalle: el harness los administra por defecto; queda pendiente mirar de cerca cómo resume, qué cachea y cómo se afina.
Export desde la CLI y despliegue en AgentCore: llevar el prototipo de la laptop a un entorno gestionado (y ahí sí, resolver la persistencia durable de sesiones).

Conclusiones

Volvamos a la promesa del principio: crear un agente en dos líneas. Es verdad, y no es poco: create_harness() te ahorra ensamblar a mano el modelo, las herramientas, la memoria, las sesiones y la gestión de contexto. Para empezar, es un salto enorme.

Pero construir algo que se sostenga pide entender lo que esas dos líneas tapan. Que un turno no es una llamada sino un bucle que puede disparar varias. Que las sesiones hacen reanudable la conversación, pero el id lo gestiona tu código, no el modelo. Que la memoria de largo plazo a veces ayuda y a veces estorba, en el narrador la apagué, porque el estado real vivía mejor en archivos. Que el contexto crece y el harness lo administra por nosotros. Y que delegar en subagentes mantiene limpio el hilo principal porque cada uno trabaja aparte y solo devuelve su conclusión.

Otro punto importante es la elección de modelos. Si tenemos la posibilidad de usar los modelos de Claude, a priori sabemos que la mayoría de las tareas las van a resolver con eficacia, pero creo que el aprendizaje pasa por la experimentación. Si estás dando tus primeros pasos, te invito a que uses todos los modelos que posean free tier. También experimentar con Docker + Ollama, bajando a tu laptop modelos pequeños y entender en qué tareas de subagentes son más óptimos.

Y una línea de diseño para construir agentes es dejá que los agentes hagan lo que requiere criterio, y que el código haga lo determinista. La prosa, la revisión de continuidad, el juicio sobre el ritmo: eso es trabajo de agentes, y es donde no se puede resolver vía código (simulando ser personas de un pequeño taller literario escribiendo y corrigiendo). El id de la sesión, la ruta del archivo, el contador de capítulos: eso es trabajo del código, determinista y predecible. Mezclarlos es justo donde aparecen las alucinaciones y bugs.

Referencias

Camino a AWS Certified Developer — Associate (DVA-C03): qué cambia y por qué

Laura Bolaños — Mon, 07 Sep 2026 22:57:21 +0000

El 1 de septiembre de 2026, AWS anunció oficialmente cambios de versión en varios de sus exámenes. Entre ellos, AWS Certified Developer — Associate. En este artículo te comparto mi experiencia con la versión actual que rendí y los cambios de lo que se viene.

🎯 Hasta el 30 de noviembre de 2026 se puede rendir la versión actual DVA-C02. El registro para DVA-C03 abre el 27 de octubre de 2026, con disponibilidad general (GA) a partir del 1 de diciembre de 2026.*

Hace unos meses escribí sobre mi experiencia rindiendo el examen DVA-C02, con los temas clave que profundicé y algunos tips de estudio. AWS acaba de anunciar la actualización a DVA-C03, y me pareció importante escribir esta continuación: no para reemplazar ese artículo, sino para sumarle lo nuevo. Si estás por empezar a estudiar hoy, mi recomendación es leer ambos: la base técnica de servicios (Lambda, DynamoDB, API Gateway, Cognito, etc.) sigue totalmente vigente, y acá vas a encontrar el "qué se agrega" y el "por qué" de esta actualización.

El calendario a tener en cuenta según el anuncio:

Por qué actualizan el examen

El blog oficial de AWS Training and Certification plantea que el rol de developer ya no es solamente escribir código de aplicación. Hoy un developer usa herramientas de AI-assisted development para generar, revisar y optimizar código; integra servicios de AI administrados dentro de sus aplicaciones; y tiene que asegurar las interacciones de agentes de AI. Es decir, AI-assisted development pasa a ser una competencia central del rol, no un "extra".

Esto no significa que el examen se convierta en una certificación de AI. De hecho, el anuncio oficial aclara qué queda fuera de alcance: prompt engineering, diseño de RAG, selección de modelos de AI, Amazon SageMaker AI y diseño de frameworks de gobernanza de AI. Es decir, no van a pedirte que diseñes soluciones de AI desde cero, sino que sepas cómo un developer integra y asegura estas capacidades dentro del ciclo de vida de una aplicación en AWS.

Datos generales de la nueva versión de examen

Según el anuncio, son los mismos parámetros generales que ya conocemos de DVA-C02:

Duración: 130 minutos
Preguntas: 65 (50 puntuadas, 15 no puntuadas)
Puntaje de aprobación: 720 sobre 1000
Precio: 150 USD
Idiomas: todos los actualmente soportados, disponibles desde el lanzamiento
Modalidad: Pearson VUE (centro de examen u online proctoring)

Lo estructural: los 4 dominios se mantienen

Buena noticia para quien ya venía estudiando: los dominios y sus porcentajes no cambian:

Development with AWS Services — 30%
Security — 26%
Testing and Deployment — 22%
Troubleshooting and Optimization — 22%

Lo que cambia es el contenido dentro de cada dominio: se consolidan skills que estaban demasiado fragmentadas, y se agregan skills nuevas relacionadas a AI y a Containers.

⭐ Tip: si ya armaste tu planilla de "brechas de conocimiento" como sugería en mi artículo anterior, no la tires. Vas a poder reusar casi todo el contenido de Lambda, DynamoDB, API Gateway, Cognito, SQS/SNS, EventBridge, Step Functions, CI/CD, CloudFormation/CDK, seguridad de datos y STS. Lo que necesitás es agregar una columna nueva para lo que sigue.

Incorporación 1: una Task completa de seguridad de AI (Task 2.3)

Esta es, para mí, la adición más relevante de todo el cambio. Dentro del dominio de Security se agrega la Task 2.3 — AI security, con 5 skills nuevas:

Gestión de accesos para servicios de AI. Aplica el mismo principio de mínimo privilegio que ya se usa para Lambda o DynamoDB, pero ahora sobre quién puede invocar un modelo, un agente o una Knowledge Base. Por ejemplo, se puede restringir con una política de recursos qué rol de IAM puede ejecutar bedrock:InvokeModel sobre un modelo específico.
Controles de privacidad de datos, principalmente vía VPC endpoints (AWS PrivateLink) y la garantía de que los inputs/outputs no se usen para entrenar modelos. Este punto no es solo teórico: el servicio nunca comparte tus datos con los proveedores de modelos ni los usa para entrenar foundation models, y todas las invocaciones se mantienen dentro de la red de AWS. Para reforzar el aislamiento de red, la guía de VPC interface endpoints de Bedrock explica que se puede crear un endpoint de interfaz (AWS PrivateLink) usando nombres de servicio como com.amazonaws.region.bedrock-runtime o com.amazonaws.region.bedrock-agent-runtime, evitando así exponer el tráfico a internet.
Content filtering y protección contra prompt injection. Acá entra Amazon Bedrock Guardrails como mecanismo central. Los content filters detectan categorías de contenido dañino (odio, insultos, contenido inapropiado, violencia, mala conducta) y, dentro de esa misma categoría, un filtro específico de prompt attacks detecta jailbreaks, prompt injections y prompt leakages. Hay que entender la diferencia entre prompt injection directo (el usuario intenta manipular el prompt) e indirecto (la instrucción maliciosa viene escondida en un dato externo, como un documento o una página web, que el agente procesa sin que el usuario lo note).
Seguridad en interacciones de agentes de AI: autorización de uso de tools, aislamiento de sesión (session isolation) y flujos de aprobación humana (human-in-the-loop). Esto conecta directo con Amazon Bedrock AgentCore Identity: este servicio provee autenticación, autorización y gestión de credenciales diseñada específicamente para agentes de AI y workloads automatizados, con identidades de workload que tienen atributos especializados para habilitar capacidades específicas de agentes, manteniendo compatibilidad con patrones estándar de identidad de workload de la industria.
Protección de contenido sensible en logs de monitoreo. Amazon Bedrock permite habilitar model invocation logging hacia CloudWatch Logs o S3, pero por defecto esos logs pueden incluir el input/output completo de cada invocación. El mecanismo para proteger datos sensibles ahí es Amazon Bedrock Guardrails (vía la API ApplyGuardrail), que permite enmascarar esa información antes de que quede registrada — mismo espíritu que ya aplicabas con StreamViewType: KEYS_ONLY en DynamoDB Streams para no exponer información sensible.

⭐ Tip de estudio: si en DVA-C02 profundizaste STS, IAM trust relationships y KMS, ya tenés el 70% del razonamiento necesario para esta Task nueva. Lo que hay que sumar es el vocabulario y los mecanismos específicos de AI (Guardrails, AgentCore Identity, PrivateLink hacia Bedrock).

Incorporación 2: AI-assisted development transversal a los 4 dominios

Esto se distribuye en los cuatro dominios:

Domain 1 (Development): generación de código y revisión automatizada.
Domain 3 (Testing and Deployment): automatización de pruebas y pruebas de regresión, y soporte para workflows de CI/CD incluyendo aprobaciones automatizadas de despliegue.
Domain 4 (Troubleshooting and Optimization): análisis de errores, sugerencias de troubleshooting y recomendaciones de optimización de performance.

Un dato importante para no confundirse en el estudio: según la documentación oficial sobre el fin de soporte de los plugins IDE de Amazon Q Developer, AWS discontinuará el soporte de estos plugins el 30 de abril de 2027, y como alternativa para capacidades similares (coding agéntico, chat, soporte MCP) recomienda explorar Kiro.
Kiro es el IDE agéntico que propone spec-driven development: convierte un prompt en requerimientos, diseño de sistema y lista de tareas antes de generar código, en lugar de saltar directo a la implementación. Como developer, puede que el examen busca que entiendas el concepto de spec-driven development como enfoque de AI-assisted development.

⭐ Tip: una lectura valida es entender en qué punto del ciclo de vida de desarrollo entra cada práctica de AI-assisted development, que es como está formulada la skill en cada dominio.

Incorporación 3: Gestión de contenedores

Construcción y gestión de imágenes de contenedor con Amazon ECR.
Despliegue de aplicaciones containerizadas con Amazon ECS, Amazon EKS y AWS Fargate.

En mi artículo anterior ya mencionaba ECS/EKS dentro de "Contenedores ECS, EKS" enfocado en monitoreo y observabilidad (CloudWatch, X-Ray) ya que no se me presentaron otro tipo de preguntas. Pero la diferencia es que en la nueva versión del examen amplía el foco: no solo observar un contenedor en ejecución, sino todo el ciclo — construir la imagen, subirla a ECR, y decidir entre ECS, EKS o Fargate según el caso de uso (gestión de clúster propia vs. serverless de contenedores).

⭐ Tip de laboratorio: armá una imagen simple, subila a ECR, y desplegarla primero en ECS con Fargate y después evaluá qué cambiaría si migraras esa misma imagen a EKS. La diferencia conceptual entre "quién administra el plano de control y los nodos" es justamente lo que suelen evaluar en preguntas de este estilo.

Incorporación 4: Nuevos servicios que entran en el alcance del examen

Amazon Bedrock → el servicio administrado para trabajar con modelos fundacionales.
Amazon Bedrock AgentCore → la plataforma para construir, desplegar y operar agentes de AI de forma segura y a escala, sin gestionar infraestructura. Se compone de Runtime (entorno serverless para correr agentes), Memory (memoria de corto y largo plazo), Gateway, Identity, herramientas built-in (ejecución de código en sandbox, browser tool) y Observability (monitoreo vía CloudWatch). Para un developer, dos piezas son especialmente relevantes:
- Gateway, porque permite convertir APIs existentes (OpenAPI, Smithy) y funciones AWS Lambda en tools compatibles con el protocolo MCP (Model Context Protocol), sin tener que gestionar esa infraestructura — reutiliza directo el conocimiento de Lambda/API Gateway que ya tenés de DVA-C02.
- Identity, porque conecta directo con la Task 2.3 de seguridad que nombré más arriba.
Amazon Q → el asistente conversacional generativo para entender, construir, extender y operar aplicaciones y recursos de AWS.
Kiro → como comenté arriba, el IDE agéntico de spec-driven development.
Amazon Data Firehose → para entrega de streams de datos a destinos como S3, Redshift o servicios de terceros; relevante si tu arquitectura de eventos (la que ya veías con EventBridge y Kinesis Data Streams) necesita alimentar pipelines de AI o analítica.
AWS PrivateLink → ya mencionado en la Task de AI security, pero también entra como servicio in-scope de forma general, para conexiones privadas VPC-a-servicio sin pasar por internet.

Lo que se consolida (menos memorizar features aislados, más criterio)

Se aclara que varias skills fragmentadas se agrupan en unidades más grandes:

Área	Antes (DVA-C02)	Ahora (DVA-C03)
DynamoDB	4 skills separadas	1 skill integral
Seguridad (cifrado y datos sensibles)	13 skills en 2 tasks	7 skills en 1 task
Testing	11 skills en 2 tasks	5 skills en 1 task
Observability	8 skills	5 skills
Optimization	9 skills	6 skills

En la práctica, significa que el examen deja de preguntar detalles muy puntuales y aislados, y empieza a evaluar más el razonamiento integrado sobre un tema (por ejemplo, DynamoDB completo como una sola competencia, en vez de partir claves, índices, capacidad y TTL en preguntas separadas). Si con la guía actual DVA-C02 ya estudiaste estos temas a fondo como yo, no vas a tener que aprender contenido nuevo acá. El cambio es más de "cómo te lo preguntan".

Cómo armaría el plan de estudio hoy hasta esperar el detalle de la nueva guía de examen

Base técnica: seguí usando mi artículo de DVA-C02 como guía de los servicios core (Lambda, DynamoDB, API Gateway, Cognito, SQS/SNS, EventBridge, Step Functions, S3, CI/CD, CDK/CloudFormation, CloudWatch/X-Ray, seguridad de datos y STS). Ahí no cambió la profundidad requerida.
Sumá una capa de AI aplicada al developer: entendé conceptualmente Amazon Bedrock, AgentCore (sobre todo Gateway e Identity), Amazon Q Developer y Kiro — no como usuario experto, sino como developer que decide cuándo y cómo integrarlos, y qué controles de seguridad aplicar (Guardrails, PrivateLink, aislamiento de sesión, human-in-the-loop).
Profundizá contenedores end-to-end: ECR para las imágenes, y el criterio de decisión entre ECS, EKS y Fargate.
Repasá la guía de examen oficial completa apenas se publique (disponible cuando abra el registro, el 27 de octubre de 2026), porque ahí van a estar los task statements detallados de cada skill.
Mantené la costumbre que ya recomendaba antes: hacé laboratorios chicos de todo lo anterior y practicar muchas preguntas de examen, más que memorizar teoría aislada.

⭐ Y el mismo disclaimer que hice en el artículo anterior sigue más vigente que nunca: cuidado con usar AI para el estudio profundo de servicios sin chequear contra documentación oficial — pueden aparecer alucinaciones si se utiliza el conocimiento del modelo que uses. Contrastá contra la documentación oficial via los MCP oficiales de AWS:
"awslabs.aws-documentation-mcp-server" y "aws-knowledge-mcp-server"

Conclusión: Si estás arrancando de cero con esta certificación, te recomiendo leer primero mi artículo sobre DVA-C02 para la base de servicios, y usar este como complemento de lo nuevo que trae DVA-C03.

Fuentes

A2A en Strands: agentes remotos con routing determinístico y discovery dinámico

Laura Bolaños — Tue, 01 Sep 2026 16:20:05 +0000

Culminando la serie de artículos que trata la orquestación de multiagentes en Strands Agents, voy a explicar cómo implementar agentes remotos con A2A y algunas de sus variantes, utilizando routing determinístico y discovery dinámico de agentes. Lo ejemplifiqué con la construcción de dos casos de uso: privacy-aware-routing y multi-agent-trip-planner. Para probarlos utilicé Gemma4 + Ollama (local) y la API de Gemini, capa gratuita.

Introducción

La idea principal es experimentar con ejemplos sencillos algunas casuísticas del protocolo de comunicación A2A en tu notebook, sin necesidad de una cuenta de AWS ni de servicios como Bedrock. Strands hace de wrapper sobre el protocolo, permitiendo una comunicación fluida con agentes de IA remotos, más allá del framework o lenguaje con el que estén implementados.

🗒 Los casos de usos que elegí

Privacy aware routing: Un asistente financiero-bancario de atención al cliente (orquestador, Gemini vía API key) necesita resolver consultas que a veces incluyen datos sensibles (ej. número de cuenta, DNI, monto de la cuenta). En lugar de resolver el agente general, el orquestador detecta cuándo la consulta toca datos sensibles y delega esa parte a un agente A2A local (servidor separado, Gemma vía Ollama, corriendo en localhost).
Multi agent trip planner: Un asistente de viajes de atención al cliente donde el orquestador (Gemini vía API key) no conoce de antemano a qué agente delegar cada parte de la consulta. En su lugar, descubre en runtime tres agentes especialistas: vuelos, hoteles e itinerario. Cada uno expuesto como servidor A2A local (Gemma vía Ollama), y decide dinámicamente a cuál invocar según lo que necesita resolver.

En las secciones siguientes cubro los conceptos clave del protocolo A2A en Strands y el diseño e implementación de los casos de uso.

Conceptos Clave

➡ Protocolo A2A en Strands

A2A (Agent-to-Agent) es un protocolo abierto —no una invención de Strands ni de AWS— que define cómo agentes que corren en procesos, máquinas o incluso organizaciones distintas se descubren y comunican entre sí por HTTP/JSON-RPC.

Strands no reinventa el protocolo: lo envuelve (wraps) con una interfaz familiar, como si invocáramos a un agente normal de Strands. El desarrollador no ve protocolo: visualiza un agente. Un ejemplo sencillo:

from strands.agent.a2a_agent import A2AAgent

# Create an A2AAgent pointing to a remote A2A server
privacy_agent = A2AAgent(endpoint="http://localhost:9000")

# Invoked exactly like a local Agent — Strands' wrapper keeps
# the A2A protocol completely hidden from the caller
result = privacy_agent("I need the balance for account 1234-5678-9")

print(result.message)
# {'role': 'assistant', 'content': [{'text': 'The balance for account 1234-5678-9 is $85,400'}]}

El constructor de A2AAgent acepta varios parámetros:

Parameter	Type	Default	Description
`endpoint`	`str`	Required	Base URL of the remote A2A agent
`name`	`str`	None	Agent name (auto-populated from agent card if not provided)
`description`	`str`	None	Agent description (auto-populated from agent card if not provided)
`timeout`	`int`	300	Timeout for HTTP operations in seconds
a2a_client_factory	ClientFactory	None	Optional pre-configured A2A client factory

Dos piezas hacen posible el wrap en Strands:

A2AServer: expone cualquier Agent de Strands como servicio A2A, publicando automáticamente un agent card en /.well-known/agent-card.json → es la carta de presentación del agente (nombre, descripción, skills que ofrece).
A2AAgent: el lado cliente. Envuelve el endpoint de un agente remoto y lo invocás con la misma interfaz que un agente local.

Al igual que un Agent local, A2AAgent soporta invocación asíncrona (invoke_async) y streaming de respuestas (stream_async). En los ejemplos de este artículo, el orquestador transmite su respuesta en streaming, mientras que cada llamada A2A a un agente remoto es sincrónica (espera la respuesta completa del especialista antes de seguir).

La metadata del agente remoto es la agent card y se puede consultar explícitamente con get_agent_card():

card = await privacy_agent.get_agent_card()

print(f"Agent: {card.name}")
print(f"Description: {card.description}")
print(f"Skills: {card.skills}")

Cada skill dentro del agent card describe una capacidad puntual del agente: un identificador, una descripción en lenguaje natural, y opcionalmente ejemplos de uso. Es lo que le permite al orquestador razonar "este agente sabe buscar vuelos" sin necesidad de que el desarrollador lo codifique explícitamente. La decisión de a quién delegar se basa en hacer match entre la consulta del usuario y las skills descubiertas.

El método anterior el que después va a cobrar protagonismo real en el ejemplo multi-agent-trip-planner: ahí el orquestador no invoca un endpoint conocido de antemano, sino que consulta las agent cards de varios agentes remotos para decidir dinámicamente a cuál delegar cada tarea.

➡ A2AAgent dentro de otros patrones de orquestación en Strands

A2AAgent se puede combinar dentro de otros patrones de orquestación multiagente en Strands.

Como tool de un agente orquestador: es exactamente el enfoque que desarrollamos en la POC privacy-aware-routing — el A2AAgent se envuelve en un @tool y el agente padre lo invoca como una función más, como si fuera un subagente.
Como nodo dentro de un Graph: un A2AAgent puede integrarse como nodo remoto en un flujo de Graph, mezclando agentes locales y remotos dentro del mismo grafo de dependencias.
En Swarm: al día de hoy NO está soportado, ya que ese patrón depende de handoffs basados en tools que el protocolo A2A todavía no contempla.

Habiendo visto el lado CLIENTE, veamos ahora cómo se expone un agente para que otros puedan consumirlo vía A2A.

➡ Creando un A2A Server

Del lado servidor, exponer un agente de Strands como servicio A2A es tan simple como envolverlo con A2AServer:

from strands import Agent
from strands.multiagent.a2a import A2AServer

def create_agent(context_id: str) -> Agent:
    return Agent(
        name="Privacy Agent",
        description="Resolves queries containing sensitive customer data",
    )

a2a_server = A2AServer(agent_factory=create_agent)
a2a_server.serve()

El servidor publica automáticamente el agent card en /.well-known/agent-card.json y queda escuchando requests A2A en el puerto configurado (por default, 9000).

Un detalle de diseño importante: se recomienda pasar un agent_factory (una función que crea un agente nuevo) en lugar de una instancia única de Agent. La razón es el aislamiento por conversación: A2A identifica cada conversación con un context_id, y el servidor crea y reutiliza un agente dedicado por cada context_id, para que distintas conversaciones nunca mezclen su historial entre sí. Pasar un único Agent compartido está deprecado!

Para los casos de uso de este artículo, ese aislamiento no es el foco central: cada servidor atiende un tipo de tarea puntual, sin mantener contexto conversacional extenso.
Pero es un concepto clave a tener presente si tu agente remoto necesita recordar el hilo de una conversación a lo largo de varios turnos.

➡ Strands A2A Tool: descubrimiento dinámico

Cuando hay varios agentes remotos disponibles y no querés hardcodear el mapeo "qué tarea va a qué agente", Strands ofrece A2AClientToolProvider (parte del paquete strands-agents-tools). Le da al agente orquestador un conjunto de tools para descubrir agentes A2A y comunicarse con ellos usando lenguaje natural:

from strands import Agent
from strands_tools.a2a_client import A2AClientToolProvider

# known_agent_urls es opcional: podés pasar endpoints conocidos
# o dejar que el provider los descubra en runtime
provider = A2AClientToolProvider(
    known_agent_urls=[
        "http://localhost:9001",  # Flights Agent
        "http://localhost:9002",  # Hotels Agent
        "http://localhost:9003",  # Itinerary Agent
    ]
)

orchestrator = Agent(tools=provider.tools)
response = orchestrator("Quiero ir a Barcelona en marzo, 5 días")

El provider expone tres capacidades:

Agent Discovery: descubre automáticamente los agentes A2A disponibles y sus capacidades (leyendo sus agent cards).
Protocol Communication: envía mensajes usando el protocolo A2A estandarizado.
Natural Language Interface: el orquestador interactúa con los agentes remotos en lenguaje natural, sin que el desarrollador tenga que codear explícitamente "si la consulta es sobre vuelos, llamá a este endpoint".

Esta es la pieza central de la POC de este articulo multi-agent-trip-planner: acá el agent card deja de ser un detalle de implementación y pasa a ser el mecanismo que le permite al orquestador razonar sobre a quién delegar cada subtarea, sin que ese mapeo esté escrito en el código.

➡ Evaluaciones (Evals)

Strands cuenta con un marco oficial para realizar evaluaciones, desde resultados simples hasta el análisis de interacciones multiagente complejas.

Para evaluar los workflows usé strands-agents-evals con el mismo provider configurado en .env (Gemini) como juez via LiteLLM para mantener el proyecto sobre una sola credencial y sin cuenta de AWS. En producción la práctica estándar es usar un modelo más capaz e independiente como judge.

En ambos proyectos combiné dos tipos de evaluación, para mostrar las dos familias que ofrece el SDK:

Determinística (código puro, sin LLM): rápida y barata, ideal para CI (Continuous Integration). Verifica la decisión del orquestador inspeccionando qué herramientas invocó (su trayectoria). Es el corazón de cada patrón A2A.
LLM-as-a-judge: un modelo puntúa, con una rúbrica, cualidades más subjetivas de la respuesta final: Correctness (¿el dato coincide con la referencia?) y Faithfulness (¿se apoya en los datos de las tools y no inventa ni evade?).

La diferencia está en qué mide la capa determinística en cada patrón, porque cada uno decide algo distinto:

	privacy-aware-routing	multi-agent-trip-planner
Qué decide el orquestador	Si delega o responde directo	A quién descubre y a quién delega
Eval determinística	La tool `handle_sensitive_query` se llama solo ante datos sensibles, y NO ante consultas genéricas	El orquestador primero descubre (`a2a_list_discovered_agents`) y luego delega (`a2a_send_message`)
Evaluadores usados	`ToolCalled` + `ToolNotCalled` (custom)	`ToolCalled` (discovery y delegación)
Eval LLM-judge	Correctness + Faithfulness sobre la respuesta del agente local	Correctness + Faithfulness sobre la propuesta de viaje integrada
Problema que detecta	El modelo local inventa un saldo en lugar de usar la tool	Un especialista inventa vuelos/hoteles/atracciones en lugar de usar su tool

Descripción de la solución

📦 Un único repositorio de GitHub con los dos proyectos: github.com/reinalau/strands-a2a-patterns

El repositorio reúne dos proyectos independientes, cada uno es un caso de uso de A2A:

privacy-aware-routing - ruteo determinístico hacia un único agente remoto: el orquestador decide, según el contenido de la consulta, si responde él mismo o delega la parte sensible a un agente que corre 100% local.
multi-agent-trip-planner - descubrimiento dinámico de agentes: el orquestador no conoce de antemano a los especialistas, sino que los descubre en runtime leyendo sus agent cards y delega cada subtarea al que corresponda. A su vez cada agente tiene tools disponibles.

Ambos comparten la misma base técnica (Strands, con Gemini como orquestador y Gemma local como agente remoto) y la misma forma de ejecutarse. El siguiente setup aplica a los dos por igual. Se usan los dos modelos, Ollama local y Gemini via Apikey:

a. Ollama + el pequeño modelo gemma4:e2b-it-qat (que pesa poco más de 4gb) ejecutando en Docker. Para esto necesitás tener Docker Desktop instalado y corriendo; una vez levantado, los comandos de abajo crean el contenedor de Ollama y descargan el modelo.
En el caso de multi-agent-trip-planner hay tres agentes remotos que pueden recibir requests casi al mismo tiempo; si querés que esas llamadas se ejecuten en paralelo, hay que indicárselo a Ollama, cuyo comportamiento por default procesa una inferencia por vez:

# Start the Ollama server with a persistent volume
docker run -d --name ollama -p 11434:11434 -v ollama_data:/root/.ollama ollama/ollama

# Start the Ollama server with real parallelism (3 simultaneous requests)
# docker run -d --name ollama -p 11434:11434 -v ollama_data:/root/.ollama -e OLLAMA_NUM_PARALLEL=3  ollama/ollama

# Download the model
docker exec -it ollama ollama pull gemma4:e2b-it-qat

# Test that the model responds
# If the container has already been created and 
# is currently stopped, simply use: docker start ollama
docker exec -it ollama ollama run gemma4:e2b-it-qat

# Verify that the model is running
docker exec -it ollama ollama ps

b. API de Gemini. La API key se puede generar de manera gratuita desde aquí y utilizar al menos estos modelos (experimentá con los que te permita tu cuenta):

gemini-3.6-flash
gemini-3.5-flash-lite

El código de los 2 proyectos está en Python y la estructura se diseñó de manera que su lógica sea más explicativa; todo el detalle lo encontrás en el README.md de cada proyecto:

strands-a2a-patterns/
├── README.md                          # Overview of both use cases
│
├── privacy-aware-routing/             # Case 1: deterministic routing, single remote agent
│   ├── README.md
│   ├── requirements.txt
│   ├── .env.example
│   ├── common/                        # shared: prompts, config, logging
│   ├── remote_agent/
│   │   ├── server.py                  # A2AServer — Gemma via Ollama
│   │   └── bank_tools.py              # mock bank tools with fixed data
│   ├── orchestrator/
│   │   └── main.py                    # Gemini — A2AAgent as tool
│   ├── tests/
│   │   ├── test_routing_logic.py      # does the orchestrator delegate when it should?
│   │   └── test_a2a_integration.py    # real integration test against the running local server
│   ├── evals/
│   │   ├── eval_routing.py            # deterministic: routing decision
│   │   └── eval_response_quality.py   # LLM-judge: correctness + faithfulness
│   └── logs/
│       └── .gitkeep                    # run logs land here (gitignored)
│
└── multi-agent-trip-planner/          # Case 2: dynamic discovery, 3 remote agents
    ├── README.md
    ├── requirements.txt
    ├── .env.example
    ├── common/                        # shared: prompts, config, logging
    ├── remote_agents/
    │   ├── travel_tools.py            # mock travel tools with fixed data
    │   ├── flights_server.py          # A2AServer — Gemma via Ollama (port 9001)
    │   ├── hotels_server.py           # A2AServer — Gemma via Ollama (port 9002)
    │   └── itinerary_server.py        # A2AServer — Gemma via Ollama (port 9003)
    ├── orchestrator/
    │   └── main.py                    # Gemini — A2AClientToolProvider
    ├── tests/
    │   ├── test_discovery.py          # does the orchestrator discover before delegating?
    │   └── test_a2a_integration.py    # real integration test against the 3 running servers
    ├── evals/
    │   ├── eval_discovery.py          # deterministic: discovery + delegation decision
    │   └── eval_response_quality.py   # LLM-judge: correctness + faithfulness
    └── logs/
        └── .gitkeep                    # run logs land here (gitignored)

Ejecución Local

Una vez que tenemos el repositorio clonado y el Docker de Ollama con el modelo gemma 4 (o la API key de Gemini generada), pasamos a armar el ambiente. Los pasos son los mismos en ambos proyectos; cada uno tiene su propio requirements.txt y su .env, así que hay que pararse dentro de la carpeta del proyecto que quieras correr.

En requirements.txt (con comentarios que explican para qué se necesita cada dependencia) encontramos:

strands-agents[a2a,ollama,litellm]>=1.0.0
strands-agents-tools>=0.1.0
python-dotenv>=1.0.0
pytest>=8.0.0
pytest-asyncio>=0.23.0
strands-agents-evals>=1.2.0

Conviene instalar las dependencias en un entorno virtual, para aislarlas del resto del sistema:

python -m venv .venv
# Activar: source .venv/bin/activate (Linux/macOS)
pip install -r requirements.txt

En .env se configuran, entre otros, la API key y el modelo del orquestador (Gemini), el modelo local (Gemma vía Ollama) y el nivel de log. Alcanza con copiar el ejemplo y completar la key:

cp .env.example .env

En common/config.py está la carga y validación de esas variables (falla temprano con un mensaje si falta la API key), y en common/prompts.py los system prompts del orquestador y de cada agente remoto.

📝 Sobre cambiar de modelo: el orquestador usa LiteLLMModel, así que no está atado a Gemini: LiteLLM soporta muchos proveedores (Anthropic, OpenAI, Bedrock, etc.). Alcanza con cambiar ORCHESTRATOR_MODEL_ID en el .env por el identificador del proveedor que quieras (con su prefijo, p. ej. anthropic/…, openai/…) y setear su API key. La lista completa está en la documentación de model providers de Strands. Del mismo modo, el agente remoto no tiene por qué correr en Ollama: podés reemplazar OllamaModel por otro provider en el código del servidor (server.py / los *_server.py).

Las pruebas están en tests/ y se pueden correr una a una (recomendado! ya que puede ser algo lento localmente) o todas juntas: unitarias rápidas (deciden si el orquestador delega/descubre cuando corresponde) e integración real contra los servidores A2A (arrancan solos como subprocesos; requieren Ollama corriendo).

python -m pytest

Procedemos a ejecutar el caso real. Acá está la diferencia práctica entre los dos proyectos: cada uno corre como varios procesos independientes, uno por terminal. Primero se levantan los agentes remotos (cada A2AServer queda escuchando en su puerto) y, con todos activos, se lanza el orquestador que los descubre y les habla por la red. El orden de arranque de los servidores no importa, pero deben estar todos activos antes de correr el orquestador.

privacy-aware-routing — 2 procesos (2 terminales):

Terminal - Comando	Rol
Terminal 1: `python -m remote_agent.server`	Agente remoto local (Gemma), expone su agent card en el puerto 9000. Cuenta con tools para responder sobre datos sensibles
Terminal 2: `python -m orchestrator.main "Quiero consultar el saldo de mi cuenta 1234-5678-9"`	Orquestador (Gemini): decide si delega y arma la respuesta

multi-agent-trip-planner — 4 procesos (4 terminales):

Terminal - Comando	Rol
Terminal 1: `python -m remote_agents.flights_server`	Especialista de vuelos (Gemma), puerto 9001
Terminal 2: `python -m remote_agents.hotels_server`	Especialista de hoteles (Gemma), puerto 9002
Terminal 3: `python -m remote_agents.itinerary_server`	Especialista de itinerario (Gemma), puerto 9003
Terminal 4: `python -m orchestrator.main "Quiero ir a Barcelona en marzo, 5 dias"`	Orquestador (Gemini): descubre los 3 agentes, delega y arma la propuesta

El orquestador acepta la consulta como argumento o, si se lo llama sin argumentos, abre un chat interactivo.
Para salir de los servidores remotos: Ctrl+C en su terminal; para salir del chat interactivo: escribí exit.

Los logs de las llamadas están en logs/, separado por proceso. Contiene la data cruda que permite seguir el intercambio A2A: qué descubrió y delegó el orquestador, y qué tool ejecutó cada agente remoto (líneas TOOL CALL: ...). Permite verificar que la respuesta salió de los datos y no de una alucinación del modelo.

El resultado final se visualiza en pantalla, en streaming (token a token).

Por último, hacemos una evaluación sobre el sistema multiagente real con el concepto de "Evals". Cada proyecto trae dos scripts: uno determinístico (verifica la decisión del orquestador) y uno LLM-as-judge (puntúa la calidad de la respuesta final). Ejecutan el flujo real contra el modelo configurado, muestran los resultados en consola y guardan el reporte completo en evals/outputs/<nombre>_<timestamp>.json. (Leer más detalle arriba en Conceptos Clave)

# privacy-aware-routing
python -m evals.eval_routing
python -m evals.eval_response_quality

# multi-agent-trip-planner
python -m evals.eval_discovery
python -m evals.eval_response_quality

Conclusiones

Los dos proyectos implementan casos de uso distintos que se apoyan en la misma base exponer agentes con A2AServer, pero difieren en cómo el orquestador consume esos agentes remotos: uno con ruteo determinístico hacia un agente conocido (A2AAgent, endpoint fijo); y el otro, mediante un descubrimiento dinámico de varios especialistas (A2AClientToolProvider, que lee los agent cards en runtime).

⭐ En ambos casos de uso, la abstracción de Strands esconde la mecánica del protocolo (resolución del agent card, HTTP, JSON-RPC). Del lado del orquestador, delegar a un proceso remoto se ve casi igual que llamar a una función local.

Algunas lecciones que dejaron las ejecuciones:

El agent card es el contrato. En el caso de discovery, la calidad de las skills publicadas (nombre y descripción) es lo que le permite al orquestador rutear bien sin mapeos hardcodeados. Un agent card incompleta degrada la decisión.
Los modelos locales chicos usan tools de forma intermitente. Con gemma4:e2b-it-qat, a veces el agente responde sin llamar la tool y ahí puede inventar datos. Por eso importa (a) instruirlo en el prompt a usar siempre la tool, y (b) verificarlo: los logs TOOL CALL: ... distinguen un dato real de una alucinación.
Evaluar los agentes exige leer el campo "reasons", no solo el score. Un 0.0 puede venir de la infraestructura (un 503 del juez, un modelo dado de baja), no de una mala respuesta.
Latencia y concurrencia son decisiones de arquitectura. La inferencia local es lenta; con tres especialistas compartiendo un Ollama secuencial, las tareas se encolan. Habilitar paralelismo (OLLAMA_NUM_PARALLEL) y ajustar los timeouts del cliente A2A cambia notablemente la experiencia.

Los dos casos ejemplificados son solo algunas variantes de A2A. Strands habilita capacidades que dejo anotadas para futuras pruebas:

Agentes remotos dentro de patrones multiagente: un A2AAgent puede ser un nodo más en un Graph workflow, mezclando agentes locales y remotos en un mismo pipeline.
Interrupciones (input_required): Similar a "human-in-the-loop", un agente remoto puede pausar una tarea y esperar una aprobación antes de continuar (por ejemplo, confirmar una reserva), y reanudar exactamente donde quedó.
Persistencia de conversaciones: con un SessionManager por context_id, cada conversación puede sobrevivir al reinicio del proceso en lugar de vivir solo en memoria.
Notificaciones push y despliegue distribuido: para tareas largas y para exponer cada agente productivamente (por ejemplo, detrás de balanceadores, en AWS Fargate o vía AgentCore), escalando el sistema más allá de una notebook.
Utilizar MCP de manera complementaria: Cada especialista puede usar MCP para sus tools y A2A para colaborar con otros.

⭐ Por último, aquí construyo los agentes en Python con Strands, pero como A2A es un estándar abierto (hoy bajo la Linux Foundation) y viaja sobre HTTP/JSON-RPC, la interoperabilidad ocurre a nivel del protocolo, no del framework. Un agente Strands puede comunicarse con agentes construidos en otros frameworks y lenguajes que también implementen A2A. El protocolo tiene SDKs oficiales en Python, JavaScript, Java, C#/.NET, Go y Rust, sin que ninguno conozca la lógica interna del otro.

Recursos

Curso Fundamentos Strands
Building AI Agent Harnesses with Strands Agents
Building AI Agent Harnesses – Video Course
Documentación Strands Agents
Evals
Agent-to-Agent (A2A) Protocol
Protocolo A2A (Agent2Agent)
Sitio oficial del protocolo A2A

Workflow en Strands: un DAG de tareas ejecutado como herramienta única

Laura Bolaños — Wed, 19 Aug 2026 21:31:31 +0000

En estas notas te explico cómo orquestar agentes con la arquitectura Workflow de Strands Agents utilizando paralelismo y join points, ejemplificado con la construcción de un entregable para preparar y gestionar reuniones como Solutions Architect. Testado de dos maneras: con Gemma4 + Ollama (local) y con la API de Gemini.

Introducción

La idea principal es experimentar con el patrón de orquestación workflow sin gastar en suscripciones pagas de tokens, dejando el deploy en AWS para otra instancia. Durante el desarrollo y testing me encontré con algunos inconvenientes de features no implementadas y descubrí proveedores de modelos soportados al día de hoy.

🗒 El caso de uso que elegí para representar el patrón de orquestación Workflow es un copiloto para Solutions Architects que prepara y cierra discovery meetings con clientes: investiga la empresa, mapea a los stakeholders, genera preguntas de discovery fundamentadas en ese contexto, resume la reunión una vez ocurrida, y sintetiza todo en un entregable de seguimiento (email + próximos pasos + gaps a resolver).

La idea del diseño se sacó del playground de PartyRock de Jeff Escott

En las secciones siguientes cubro los conceptos claves del patrón, el diseño e implementación del caso de uso, los hallazgos reales de ejecución con ambos modelos, y las evaluaciones con strands-agents-evals.

Conceptos Claves

➡ Workflow de Agentes es un patrón de orquestación coordinado en una secuencia definida.

Cada Agente realiza una serie de tareas definidas. El desarrollador puede descomponer tareas complejas en componentes manejables y distribuirlos entre agentes especializados. Cada workflow tiene un control explícito del orden de ejecución de las tareas, las dependencias y el flujo de información entre tareas.

Workflow es apropiado:

Cuando se tiene un proceso complejo pero repetible que se desea encapsular en una herramienta única, confiable y reutilizable, un Workflowes un grafo de tareas definido por el desarrollador que un agente puede ejecutar como una acción única y potente.
Si tenemos complejidad en los procesos con múltiples pasos, resolución de tareas con distintas etapas secuenciales.
Procesos que requieren subagentes especializados en cada etapa o un seguimiento detallado en cada paso
Ejecutar tareas independientes en paralelo, mientras hay gestión de independencias. De esta manera optimizamos recursos.
Si tenemos que reintentar pasos por error tareas especificas sin reiniciar todo el flujo.

Para clarificar las diferencias entre patrones de orquestación, te muestro una comparativa entre workflow, graph y swarm. La mayor diferencia a considerar es cómo se determina la ruta de ejecución :

	Workflow	Graph	Swarm
Concepto fundamental	Un grafo de tareas predefinido (DAG) ejecutado como una herramienta única y no conversacional.	Un flowchart estructurado y definido por el desarrollador, donde un agente decide qué camino tomar.	Un equipo dinámico y colaborativo de agentes que se pasan las tareas de forma autónoma.
Estructura	Un desarrollador define todas las tareas y sus dependencias en el código.	Un desarrollador define todos los nodos (agentes) y aristas (transiciones) con antelación.	Un desarrollador proporciona un pool de agentes. Los propios agentes deciden el camino.
Flujo de ejecución	Determinista y paralelo. El flujo está determinado por el grafo de dependencias. Las tareas independientes se ejecutan en paralelo.	Controlado pero dinámico. El flujo sigue los bordes del grafo, pero la decisión de un LLM en cada nodo determina el camino (path).	Secuencial y autónomo. Un agente ejecuta una tarea y luego cede el control a otro agente adecuado en el enjambre.
¿Permite ciclo?	NO.	SÍ.	SÍ.
Mecanismos de compartir estados	La herramienta captura automáticamente los outputs de las tareas y los pasa como inputs a las tareas dependientes.	Se pasa un objeto de estado compartido a todos los agentes, quienes pueden leerlo y modificarlo libremente.	Todos los agentes disponen de un contexto compartido o memoria de trabajo, que contiene la solicitud original, el historial de tareas y el conocimiento de los agentes anteriores.
Historial de conversaciones	Contexto específico de la tarea. Una tarea recibe un resumen curado de los resultados relevantes de sus dependencias, no el historial completo.	Transcripción completa. Todo el historial de diálogo forma parte del estado compartido, lo que proporciona a cada agente un contexto completo y abierto.	Transcripción compartida. El contexto compartido proporciona un historial completo de los handoffs de agentes y el conocimiento aportado por agentes anteriores, disponible para el agente actual.
Control del comportamiento	La solicitud del usuario puede activar un workflow predefinido, pero no puede alterar su estructura interna.	La información que introduce el usuario en cada paso puede influir directamente en la ruta que seguirá el grafo a continuación.	La indicación inicial del usuario define el objetivo, pero a partir de ahí el Swarm corre de forma autónoma.
Escalabilidad	Escala bien en operaciones repetibles y complejas.	Escala bien en procesos complejos(muchas ramificaciones, condiciones).	Escala en función del número de agentes especializados en el equipo y de la complejidad de la tarea colaborativa.
Manejo de errores	Sistémico. Un fallo en una tarea detendrá todas las tareas dependientes posteriores. Es probable que todo el workflow entre en estado `failed`.	Controlable. Un desarrollador puede definir aristas de "error" explícitas para dirigir el flow a un nodo de error-handling si falla un paso.	Agent-driven. Un agente puede decidir transferir la tarea a un especialista en manejo de errores. El sistema se basa en tiempos de espera y límites de transferencia para evitar bucles infinitos.

➡ Conceptos genéricos de Workflow agénticos

Para la implementación del caso de uso, solo usé la workflow tool, una de las ~45 tools nativas disponibles en strands-agents-tools.

Componentes claves en la arquitectura:

⭐Definición y distribución de tareas. Cada tarea necesita una descripción especifica de qué debe lograr el agente, una asignación que haga matching con el agente adecuado según sus capacidades, y un nivel de prioridad que determine qué se ejecuta primero cuando hay margen de elección.

⭐Gestión de dependencias. Algunas tareas deben ejecutarse en un orden específico (dependencias secuenciales), mientras que las tareas independientes pueden correr en simultáneo (ejecución paralela). En la ejecución paralela tener en cuenta que el modelo de IA que se utilice debe permitirlo.
Los join points son los puntos donde varios caminos paralelos convergen antes de continuar. En el caso de uso elegido, los dos join points son discovery_questions (espera a company_research + stakeholder_mapping) y follow_up_actions (espera a discovery_questions + meeting_summary).

⭐Flujo de información. El mapeo de input/output conecta la salida de un agente con la entrada de otro, la preservación de contexto mantiene la información relevante a lo largo de todo el workflow, y la gestión de estado permite trackear el progreso general del workflow.

Parámetros básicos del workflow:

action → create, start, status (indica si hubo error o no), list, delete.

workflow_id → identificador único del workflow.

tasks → lista de tareas con sus correspondientes propiedades

Algunas propiedades dentro de cada task:
task_id : Obligatorio. Identificador o nombre de la tarea.

description: Obligatorio. se completa con un resumen de lo que hace la tarea, es un pequeño prompt.

dependencies: Opcional. Encadenas una tarea con la otra para que no se ejecute si las dependencias aún no culminaron.

system_prompt: Obligatorio.

priority: Propiedad numérica que indica prioridad en la ejecución por el modelo.

tools: Opcional. Pero si no lo especificás puede que en la inferencia el modelo decida usar cualquier tool nativa y entre en un loop infinito.
Si no querés que la tarea ejecute ninguna tool se puede especificar cómo "tools": NO_TOOLS, esto no es un valor oficial del SDK, es un workaround verificado empíricamente: se pasa un nombre de tool que no existe en el registry, forzando al sub-agente a correr sin tools. Pasar "tools": [] no funciona porque es falsy en Python y el workflow lo ignora heredando todo el toolset del agente padre.

➡ Topologías de Secuencias y Workflow

En Strands Agents, "Workflow" puede referirse a dos cosas distintas: una arquitectura secuencial que se implementa manualmente encadenando agentes en código Python, o la Workflow Tool (strands-agents-tools), que gestiona dependencias, paralelismo y pasaje de contexto automáticamente.

Workflow Secuencial

En la topología secuencial, cada agente es un objeto Python independiente y el desarrollador conecta las salidas manualmente. Es la forma más simple de encadenar agentes, pero no hay gestión automática de dependencias ni paralelismo.

from strands import Agent
# Create specialized agents
agent1 = Agent(system_prompt="You are Agent 1. Perform the first step.", callback_handler=None)
agent2 = Agent(system_prompt="You are Agent 2. Perform the second step.", callback_handler=None)
agent3 = Agent(system_prompt="You are Agent 3. Perform the final step.")

# Sequential workflow processing
def process_workflow(input_data):
    step1_result = agent1(f"Process: {input_data}")
    step2_result = agent2(f"Process: {step1_result}")
    final_result = agent3(f"Process: {step2_result}")
    return final_result

Workflow Tool

La Workflow Tool gestiona dependencias, paralelismo y pasaje de contexto automáticamente. El desarrollador define la estructura (tasks + dependencies) y la tool se encarga del resto: qué corre en paralelo, qué espera, y qué contexto inyecta a cada tarea dependiente.

from strands import Agent
from strands_tools import workflow

# Create an agent with workflow capability
agent = Agent(tools=[workflow])

# Create a multi-agent workflow
agent.tool.workflow(
    action="create",
    workflow_id="generic_workflow",
    tasks=[
        {
            "task_id": "task1",
            "description": "Description of the first task",
            "system_prompt": "You perform the first task.",
            "priority": 5
        },
        {
            "task_id": "task2",
            "description": "Description of the second task",
            "dependencies": ["task1"],
            "system_prompt": "You perform the second task.",
            "priority": 3
        },
        {
            "task_id": "task3",
            "description": "Description of the third task",
            "dependencies": ["task2"],
            "system_prompt": "You perform the third task.",
            "priority": 2
        }
    ]
)

# Execute workflow (parallel processing where possible)
agent.tool.workflow(action="start", workflow_id="generic_workflow")
# Check results
status = agent.tool.workflow(action="status", workflow_id="generic_workflow")

➡ Evaluaciones (Evals)

Strands cuenta con una marco oficial para realizar evaluaciones de resultados simples hasta el análisis de interacciones de multiagentes complejos.

Para evaluar el workflow usé strands-agents-evals con el mismo provider configurado en .env (Gemini u Ollama) como juez. En producción la práctica estándar es usar un modelo más capaz como judge (ej. el workflow corre con gemini-2.0-flash y el judge usa gemini-2.5-pro), pero para este proyecto educativo se unifica por simplicidad.

Combiné dos tipos de evaluación:

LLM-as-a-judge — el modelo evalúa la calidad del output final:

Evaluador	¿Qué evalúa?	Escala
`OutputEvaluator`	Verifica que `follow_up_actions` tenga las 3 secciones obligatorias (email, next steps, gaps) y que el contenido esté fundamentado en los datos reales de la reunión.	0 / 0.5 / 1
`HelpfulnessEvaluator`(1)	Evalúa si el entregable final es útil para un Solutions Architect — no solo si tiene el formato correcto. (Es una instancia de OutputEvaluator con rubric propio, no una clase separada del SDK!)	0 / 0.5 / 1

(1)HelpfulnessEvaluator del SDK requiere trazas OpenTelemetry que la Workflow Tool no provee. Se reemplazó por un segundo OutputEvaluator con rubric de helpfulness.
Cuando usé HelpfulnessEvaluator del SDK, el score devolvió 0.0 con el error: "Trace parsing requires actual_trajectory to be a Session object, got NoneType". El evaluador espera un objeto Session de Strands (que debe contener trazas OpenTelemetry de la ejecución del agente), no solo el texto del output.

Métricas deterministas — evalúan propiedades estructurales del patrón, sin llamadas a LLM:

Métrica	¿Qué mide?
`task_completion_rate`	Fracción de tasks que completaron con `status="completed"` en el JSON persistido.
`join_point_coverage`	Verifica que ambos join points produjeron output no vacío, confirma que la inyección de contexto funcionó.
`required_sections`	Check determinista de las 3 secciones del entregable (email, next steps, gaps).
`stakeholder_coverage`	Verifica que cada stakeholder del input aparece en `discovery_questions`, confirma que el contexto de `stakeholder_mapping` llegó al join point #1.
`keyword_presence`	Presencia de keywords de dominio (con soporte de sinónimos via `\

Descripción de la solución

📦 Repositorio GitHub: github.com/reinalau/strands-workflow

Para la prueba de concepto utilicé dos opciones locales de ejecución que permitió analizar sus resultados, pero se puede utilizar solo una:
a. Ollama + el pequeño modelo gemma4:e2b-it-qat (que pesa poco mas de 4gb) ejecutando en Docker.
En caso que quieras ejecutar realmente las task que son independientes en paralelo, hay que indicarselo a ollama (sino el comportamiento por default es secuencial) :
{% raw %}

# Start the Ollama server with a persistent volume
docker run -d --name ollama -p 11434:11434 -v ollama_data:/root/.ollama ollama/ollama

# Start the Ollama server en parallel
# docker run -d --name ollama -p 11434:11434 -v ollama_data:/root/.ollama -e OLLAMA_NUM_PARALLEL=3  ollama/ollama

# Download the model
docker exec -it ollama ollama pull gemma4:e2b-it-qat

# Test that the model responds
# If the container has already been created and 
# is currently stopped, simply use: docker start ollama
docker exec -it ollama ollama run gemma4:e2b-it-qat

# Verify that the model is running
docker exec -it ollama ollama ps

b. Api de gemini. La api key se puede generar de manera gratuita desde aquí y utilizar algunos de estos modelos (experimentar con los que te permita):

gemini-2.5-flash-lite
gemini-2.5-flash
gemini-3.5-flash
gemini-3.5-flash-lite

El código está en Python y la estructura del proyecto se diseñó de manera que sea más explicativo su lógica, todo el detalle lo encontrás en el Readme.md del proyecto:

strands-workflow/
├── README.md
├── requirements.txt                  # strands-agents[litellm,ollama], strands-agents-tools, pydantic, pytest
├── .env.example                      # MODEL_PROVIDER, GEMINI_API_KEY, OLLAMA_MODEL_ID
├── .gitignore
├── pytest.ini                        # pythonpath=. so tests/ and evals/ resolve src./config imports
│
├── src/
│   ├── __init__.py
│   ├── config.py                     # get_model_config(): single global provider (Gemini or Ollama) via MODEL_PROVIDER env var
│   ├── main.py                       # Entry point: builds tasks, creates+starts the workflow, assembles the final .md
│   │
│   ├── agents/
│   │   ├── __init__.py
│   │   └── prompts.py                # System prompts per task_id (company_research, stakeholder_mapping, etc.)
│   │
│   ├── workflow/
│   │   ├── __init__.py
│   │   ├── builder.py                # build_tasks(): builds the task list — task_id, dependencies, priority
│   │   ├── deliverable.py            # Reads the persisted workflow JSON and assembles the final .md
│   │   └── instrumentation.py        # Timing hook: logs START/END + duration per task
│   │
│   ├── models/
│   │   └── schemas.py                # Pydantic: DiscoveryMeetingInput
│   │
│   └── utils/
│       ├── logging_config.py         # Tees stdout+stderr to logs/, optional DEBUG level
│       └── report_export.py          # Writes the final .md to outputs/
│
├── tests/
│   ├── __init__.py
│   ├── test_config.py                # get_model_config(): provider resolution + error if API key is missing
│   ├── test_workflow_structure.py    # Validates the workflow is well-formed: no cycles, existing dependencies, correct join points
│   ├── test_schemas.py               # Pydantic validation of DiscoveryMeetingInput
│   ├── test_report_export.py         # Generates the .md from a mocked workflow JSON
│   └── test_instrumentation.py       # Verifies install_task_timing_hooks() logs START/END with duration, without calling a real LLM
│
├── examples/
│   └── sample_input.json             # Sample input to run the workflow quickly
│
├── evals/
│   ├── __init__.py
│   ├── evaluate_workflow.py          # strands-evals runner: OutputEvaluator + HelpfulnessEvaluator + deterministic metrics
│   ├── metrics.py                    # Domain metrics: task completion rate, join point coverage, required sections, stakeholder coverage, keyword presence
│   └── test_cases/
│       └── workflow_eval_cases.json  # Input + expected properties per eval case
│
├── logs/
│   └── .gitkeep                      # logs/run_<timestamp>.log, gitignored otherwise
│
└── outputs/
    └── .gitkeep                      # .md generated per run, gitignored otherwise

Ejecución Local

Una vez que tengas el repositorio del código fuente clonado y el docker de ollama con el modelo gemma 4 o la api key de gemini generada, pasamos armar el ambiente.

Los requerimientos que vas a encontrar en requirements.txt :

strands-agents[litellm,ollama]==1.52.0
strands-agents-tools==0.8.6
ollama==0.5.1
pydantic==2.13.4
pytest==8.3.4
strands-agents-evals>=1.0.0
python-dotenv==1.0.1

pip install -r requirements.txt

En .env se necesitan estos valores. Notar que depende el modelo que elegimos podemos intercambiar el MODEL_PROVIDER:

# Select ONE provider: "ollama" or "gemini"
MODEL_PROVIDER=ollama

# --- Gemini (only required if MODEL_PROVIDER=gemini) ---
# Free tier key: https://aistudio.google.com/apikey
GEMINI_API_KEY=YourApiKey
GEMINI_MODEL_ID=gemini-3.5-flash-lite

# --- Ollama (only used if MODEL_PROVIDER=ollama) ---
# Must have the Ollama daemon running locally: https://ollama.com
# Pull the model first: ollama pull gemma4:e2b-it-qat
OLLAMA_MODEL_ID=gemma4:e2b-it-qat
OLLAMA_HOST=http://localhost:11434

# --- Workflow persistence ---
# Redirects strands_tools' internal workflow state JSON into logs/ instead of
# the default ~/.strands/workflows/ — keeps everything from one run together.
STRANDS_WORKFLOW_DIR=logs/workflows

cp .env.example .env

En src/config.py está la configuración de ejecución, en este caso de uso utilicé parámetros como la temperature y max_tokens (limita los tokens que pueden gastar los agentes).
→ Si optas por ejecutar con el provider ollama hay que tener en cuenta el valor de la ventana de contexto: num_ctx.
→ Si optas por ejecutar con la apikey de Gemini, en el SDK de Strands, el dispatcher create_model que usa workflowinternamente soporta estos modelos solo vía litellm ("model_provider": "litellm")

Las pruebas están organizadas en tests/ en un solo nivel: ejecución rápida y determinista. Validan la estructura del workflow (sin ciclos, dependencias existentes, join points correctos), el schema del input con Pydantic, la exportación del .md desde un JSON mockeado, y los hooks de timing (sin llamadas al LLM).

python -m pytest

Ejecución del Workflow principal. En examples/sample_input.txtestá el input de ejemplo en un formato json:

{
"company_name": "...",
"known_challenges": "...",
"stakeholders": "...",
"raw_meeting_notes": "..."
}

Se puede ejecutar contra el modelo ollama local o vía api de gemini comentado más arriba.

python -m src.main

🎯 Un bug real: durante las pruebas descubrí que usando Gemini con paralelismo real puede hacer crashear el proceso de forma intermitente (y no es un problema de Windows, ocurre también en Linux). La causa es un bug conocido y abierto en LiteLLM: el cliente HTTP que usa para el streaming de Gemini es un singleton global que no distingue entre los distintos event loops que crea cada tarea del workflow al correr en paralelo.
Solución aplicada: limitar la ejecución a un hilo por vez cuando el proveedor es Gemini, vía la env var STRANDS_WORKFLOW_MAX_THREADS=1 de Strands.

El log de las llamadas del workflow está en logs/. Contiene la data cruda que permite verificar si hubo paralelismo, cuanto tiempo tarda cada task, etc.

El resultado final
Es un documento markdown con diferentes secciones como:
Company Research - Stakeholder Mapping - Meeting Summary - Discovery Questions - Follow-up Deliverable and Gap
Se guarda en outputs/discovery_meeting_yyyymmdd_hhmmss.md.

Por último, hice una evaluación de pruebas sobre el workflow multiagente real con el concepto de "Evals". Ejecuta el workflow completo contra el modelo configurado, corre los evaluadores LLM-as-judge y las métricas deterministas, muestra los resultados en consola y guarda el reporte completo en outputs/eval_report_<timestamp>.json.

python  -m  evals.evaluate_workflow

📝 Nota: La explicación del código fuente y paso a paso de la ejecución se encuentra detallado en el README.md en github .

Conclusiones y lecciones aprendidas

El patrón Workflow en Strands resuelve en lineas generales lo que indica su documentación. Dependency resolution, paralelismo real y context passing automático entre join points funcionaron correctamente y sin código extra de orquestación. El DAG se ejecuta en el orden correcto y los join points reciben el contexto inyectado de sus dependencias sin intervención manual.
La Workflow Tool de Strands está en maduración activa. pause/resume están documentados como Advanced Features pero no implementados — al ejecutarlos devuelven "🚧 Action '...' is not yet implemented", verificado contra el código fuente instalado. El workflow puede quedar colgado indefinidamente si una task termina en error (el loop interno gira para siempre esperando dependientes que nunca se vuelven "ready"). El resultado de cada task no se expone via API... hay que leer el JSON persistido directamente.
Algunos comportamientos requieren workarounds no oficiales. La herencia de tools en sub-agentes no está documentada. Por defecto cada sub-agente hereda todo el toolset del padre, incluida la workflow tool, lo que con modelos agénticos lleva a llamadas recursivas reales. "tools": [] (lista vacía) no funciona como restricción porque es falsy en Python — la solución es NO_TOOLS (["__no_tools__"]), un placeholder que fuerza filtered_tools a quedar vacío. No encontré hooks públicos para observar timing por task, se requiere monkeypatch sobre WorkflowManager.execute_task.
Los hooks de Strands tienen un mecanismo LimitToolCounts (via BeforeToolCallEvent) que permite cancelar una tool cuando se invoca más veces de lo permitido, útil como guardrail contra loops. Sin embargo, no aplica al bug de herencia de la Workflow Tool, ese mecanismo actúa sobre el agente padre, pero los sub-agentes creados internamente por el framework son instancias separadas sobre las que no hay control para registrar hooks desde afuera. Por eso "tools": NO_TOOLS sigue siendo la solución correcta.
Concurrencia del workflow tool con Gemini. Cuando hay tasks en paralelo + LiteLLM/aiohttp, se produce un RuntimeError: Task <...> got Future <...> attached to a different loop intermitente. Cada task corre en su propio thread con su propio asyncio.run(), y el cierre del connector de aiohttp cae en el loop equivocado. Se solucionó colocando una variables de entorno de Strands STRANDS_WORKFLOW_MAX_THREADS=1, limitando la concurrencia. (esto no sucede con Ollama-Gemma4 via Docker).

Recursos

Curso Fundamentos (hacelos!)
Building AI Agent Harnesses with Strands Agents
Building AI Agent Harnesses – Video Course
Documentación Strands Agents
Agent Workflows
Evals
Otros
5 Multi-Agent Patterns in Strands

Graph en Strands: Parallel + Aggregation y Feedback Loop para construir Knowledge Graphs

Laura Bolaños — Wed, 12 Aug 2026 15:19:12 +0000

Siguiendo con la serie de artículos sobre la orquestación de multiagentes en Strands, le toca el turno a Graph Multi-Agent Pattern, ejemplificado con la construcción de un knowledge graph en base a un input de texto (abstract), donde los nodos de un grafo determinista tienen las responsabilidades divididas para lograrlo. Se probó de dos maneras: con Gemma4 + Ollama y con la API de Gemini en su capa gratuita.

Introducción

La información del presente artículo la podés seguir teniendo alguna noción sobre agentes y grafos. Pero te propongo hacer un curso de fundamentos del framework Strands Agents, para que en futuros proyectos puedas dar mayor complejidad a tus agentes. La idea principal es experimentar con el patrón sin gastar en suscripciones pagas de tokens, dejando la implementación en AWS para otra instancia.

✳ El caso de uso que elegí para representar el patrón Graph es la Extracción de entidades/relaciones para formar un Knowledge Graph con validación. Se me ocurrió hacer algo útil para la comunidad académica, un mecanismo de extracción de conocimiento que sea capaz de tomar parte de un artículo científico e ingestar lo más importante en un documento json, que pueda ser legible por humanos y sistemas. La solución es un pipeline de construcción de knowledge graph a partir de un texto (ej. un abstract), usando la topología Parallel Processing→ with Aggregation→ Feedback Loop.
El diseño es una versión reducida de arquitecturas multi-agente real para enriquecimiento de knowledge graph descritos en:

Revolutionizing Knowledge Graphs with Multi-Agent Systems: AI-Powered Construction, Enrichment, and Applications

Conceptos Claves

➡ Graph es un patrón de orquestación de agentes determinista
El desarrollador define explícitamente la topología de ejecución: qué nodos existen, en qué orden corren, y bajo qué condiciones se transita de uno a otro. Cada nodo es un agente y a diferencia de otros patrones como Swarm, donde el flujo surge de la negociación entre agentes, en Graph el flujo está fijado de antemano como un grafo dirigido (DAG o con ciclos controlados).

Graph es apropiado cuando:

La estructura de dependencias es conocida de antemano: sabés qué pasos necesitan el resultado de otros antes de poder ejecutarse.
Hay paralelismo real que después converge: varios agentes pueden trabajar al mismo tiempo sobre partes independientes del problema, y sus resultados se consolidan en un punto de agregación explícito.
Se necesita revisión con ciclos controlados: un resultado puede requerir corrección y volver a un paso anterior (feedback loop), con límites de seguridad (set_max_node_executions) que garantizan que el proceso termine.
La trazabilidad y el control son prioritarios: como cada nodo y cada transición son explícitos, es más fácil auditar, debuggear y predecir el comportamiento, es bueno en contextos con validación humana o compliance.

➡ Conceptos genéricos de Grafos Agenticos

El framework propone una interfaz sencilla para la construcción de grafos, con 3 componentes base: GraphNode, GraphEdge, GraphBuilder

1.Los nodos representan agentes, nodos personalizados o sistemas multiagente. Ej:

from strands import Agent
from strands.multiagent import GraphBuilder

# Build the graph
builder = GraphBuilder()

# Add nodes
builder.add_node(agent_1, "[node_id_1]")
builder.add_node(agent_2, "[node_id_2]")

2.Las aristas definen las dependencias y el flujo de información entre los nodos. Además se puede agregar lógica condicional (no lo utilicé en el caso de uso analizado):

# Add edges (dependencies)
builder.add_edge("[node_id_1]", "[node_id_2]")

3.La ejecución sigue la estructura del grafo, respeta dependencias, la salida de un nodo se convierte en la entrada de su dependiente. Y en el caso de que varios nodos tienen aristas hacia un nodo de destino, el comportamiento predeterminado para la ejecución del destino puede variar según el SDK (Python utiliza semánticas OR: el nodo destino se dispara en cuanto cualquiera de sus dependencias completa).
4.Compatibilidad con patrones anidados, un grafo como nodo dentro de otro grafo.
5.Remote Agents vía A2A: Graph soporta agentes remotos como nodos a través de A2AAgent, para arquitecturas distribuidas donde la orquestación corre localmente pero tareas especializadas se ejecutan en servicios remotos.
6.Cyclic graph permite que un nodo sea revisitado dentro del mismo flujo, con límites de ejecución y gestión de estado.
7.Custom Node Types: Graph permite extender MultiAgentBase para crear nodos que ejecutan funciones Python deterministas en lugar de llamar a un LLM, útil para lógica de negocio, validaciones y pipelines de procesamiento de datos dentro del mismo grafo.
8.Graphs as a Tool: mediante el paquete strands_tools, un agente puede recibir el graph como tool y construir/ejecutar su propia topología de nodos en tiempo real, dejando que el LLM decida dinámicamente la orquestación en lugar de definirla de antemano con GraphBuilder.

➡ Topologías comunes
Strands documenta 4 topologías base que cubren la mayoría de casos de uso, y se pueden combinar según la complejidad del problema. Sequential Pipeline sirve cuando cada paso depende estrictamente del anterior. Parallel + Aggregation es ideal cuando hay trabajo independiente que puede correr simultáneamente y luego converger en un solo resultado. Branching Logic permite que el flujo tome caminos distintos según el contenido generado en un paso previo. Y Feedback Loop habilita ciclos de revisión con vuelta atrás, para casos donde un resultado necesita validación antes de darse por definitivo.

➡ Evaluaciones (Evals) Strands cuenta con una marco oficial para realizar evaluaciones de resultados simples hasta el análisis de interacciones de multiagentes complejos.
En el caso de uso para la creación de Knowledge Graph se realizaron 6 evaluaciones (3 sin utilizar el framework).

Evaluación / Métrica	Tipo / Origen	¿Qué evalúa?	Escala
OutputEvaluator	LLM-as-a-Judge (`strands-agents-evals`)	Verifica que la salida del nodo Publisher sea un JSON válido (`entities` y `relations`) y que las relaciones estén fundamentadas fácticamente en el texto original.	0 / 0.5 / 1
SemanticCorrectnessEvaluator	LLM-as-a-Judge (`strands-agents-evals`)	Compara semánticamente el knowledge graph generado contra las relaciones esperadas (ground truth), dando crédito parcial a triples con distinto wording pero igual significado. Implementado como un segundo `OutputEvaluator` con rúbrica de referencia, ya que el `CorrectnessEvaluator` oficial requiere un objeto `Session` de Strands (incompatible con grafos multi-agente).	0 / 0.5 / 1
Exact-Match (P / R / F1)	Métrica Determinista (`metrics.py`)	Mide la coincidencia exacta (normalizada a minúsculas/espacios) entre las triples extraídas y las triples de referencia del caso de prueba.	0.0 – 1.0
Loop Iterations Count	Métrica de Topología (`metrics.py`)	Cuenta cuántas iteraciones de revisión ocurrieron en el feedback loop entre el Validator y el Aggregator antes de la aprobación final.	entero ≥ 0
Bias-Flag Rate	Métrica Determinista (`metrics.py`)	Detecta si la respuesta del nodo Validator levantó alguna objeción o alerta de sesgo/desbalance en las relaciones o entidades analizadas.	`true` / `false`
Compound Entity Check	Métrica Determinista (`metrics.py`)	Chequeo de regresión: detecta entidades compuestas (ej. "entities and relations") que deberían haberse dividido en dos nodos separados, según la regla en `extractor_agent.py`/`aggregator_agent.py`.	lista de entidades detectadas

Para clarificar: una triple es la unidad básica de información que compone un Knowledge Graph. Representa una afirmación o hecho estructurado combinando tres elementos:

$$\text{(Sujeto)} \xrightarrow{\quad\text{Relación / Predicado}\quad} \text{(Objeto)}$$

Sujeto (source): La entidad de origen (ej. "Laura Bolaños").
Relación (relation): El tipo de vínculo o conector (ej. "born_in").
Objeto (target): La entidad de destino (ej. "Argentina").

Descripción de la solución

📦 Repositorio GitHub: github.com/reinalau/strands-graph

⭐ El caso de uso combina dos topologías: paralelismo con agregación, seguido de un ciclo de feedback antes de publicar el resultado final. Notar en la representación que Extractor es un agente que se instancia 3 veces, una única definición de agente, instanciada 3 veces (una por chunk_number) dentro del loop en builder.py.

Para la prueba de concepto utilicé dos opciones locales de ejecución que me permitió analizar sus resultados, pero podes utilizar solo una:
a. Ollama + el pequeño modelo gemma4:e2b-it-qat (que pesa poco mas de 4gb) ejecutando en Docker:

# Start the Ollama server with a persistent volume
docker run -d --name ollama -p 11434:11434 -v ollama_data:/root/.ollama ollama/ollama

# Download the model
docker exec -it ollama ollama pull gemma4:e2b-it-qat

# Test that the model responds
# If the container has already been created and 
# is currently stopped, simply use: docker start ollama
docker exec -it ollama ollama run gemma4:e2b-it-qat

# Verify that the model is running
docker exec -it ollama ollama ps

b. Api de gemini. La api key se puede generar de manera gratuita desde aquí y utilizar al menos estos modelos (experimentar con los que te permita):

gemini-2.5-flash-lite
gemini-2.5-flash
gemini-3.5-flash
gemini-3.5-flash-lite

El código del multiagente Graph está en Python y la estructura del proyecto se diseñó de manera que sea más explicativo su lógica:

strands-graph/
├── README.md                        # Project overview, setup, and usage instructions
├── requirements.txt                  # Python dependencies (strands-agents[gemini,ollama], strands-agents-evals, pydantic, etc.)
├── .env.example                      # Template for API keys (GEMINI_API_KEY) and Ollama config
├── .gitignore
│
├── src/
│   ├── __init__.py
│   ├── config.py                     # Model configs: role -> provider mapping (Gemini/Ollama), get_model()
│   ├── main.py                       # Entry point: builds graph, runs on input, prints/exports result, saves run log
│   │
│   ├── agents/
│   │   ├── __init__.py               # Re-exports all create_*_agent() factories
│   │   ├── coordinator_agent.py      # Entry point: splits input text into chunks for parallel extraction
│   │   ├── extractor_agent.py        # Shared extractor logic, instantiated 3x (one per chunk); no compound entities
│   │   ├── aggregator_agent.py       # Conflict resolution: merges, deduplicates, splits any compound entities
│   │   ├── validator_agent.py        # structured_output_model: checks format, consistency, completeness, bias
│   │   └── publisher_agent.py        # Formats and exports the final validated KG
│   │
│   ├── graph/
│   │   ├── __init__.py
│   │   ├── builder.py                # GraphBuilder setup: 7 nodes, edges (incl. aggregator->publisher), entry point
│   │   └── conditions.py             # Edge conditions: needs_revision, is_approved, all_dependencies_complete
│   │
│   ├── models/
│   │   └── schemas.py                # Pydantic schemas: Relation, KnowledgeGraph, ValidatorOutput
│   │
│   └── utils/
│       ├── logging_config.py         # Debug logging + tee_console_to_file (saves full run output to logs/)
│       └── kg_export.py              # Parses and exports final KG to JSON
│
├── tests/
│   ├── __init__.py
│   ├── test_conditions.py            # Unit tests for all_dependencies_complete, needs_revision, is_approved
│   ├── test_kg_export.py             # Unit tests for parse_publisher_output (valid/invalid JSON, schema mismatch)
│   ├── test_metrics.py               # Unit tests for evals/metrics.py, incl. find_compound_entities regression check
│   ├── test_schemas.py               # Unit tests for Relation/KnowledgeGraph/ValidatorOutput validation
│   └── test_settings.py              # Unit tests for get_model role/provider resolution and missing API key error
│
├── examples/
│   └── sample_input.txt              # Short input text used as the default demo run
│
├── evals/
│   ├── __init__.py
│   ├── test_cases/
│   │   └── kg_extraction_cases.json  # Input texts + expected relations for evaluation
│   ├── evaluators.py                 # Custom Strands Evals SDK evaluators (precision/recall, feedback loop)
│   ├── evaluate_graph.py             # Strands Evals SDK runner: Case/Experiment against test cases
│   └── metrics.py                    # Domain metrics: precision/recall, loop iterations, bias-flag rate, compound entities
│
├── logs/
│   └── .gitkeep                      # Full console output per run (logs/run_<timestamp>.log), gitignored otherwise
│
└── outputs/
    └── .gitkeep                      # Generated KG JSON + eval reports land here, gitignored otherwise

Ejecución Local

Una vez que tenemos el repositorio del código fuente clonado y el docker de ollama con el modelo gemma 4 o la api key de gemini generada, pasamos armar el ambiente.

Los requerimientos que vamos a encontrar en requirements.txt:
strands-agents[gemini,ollama]>=1.0.0
strands-agents-tools>=0.1.0
strands-agents-evals
python-dotenv>=1.0.0
pydantic>=2.0.0
pytest

pip install -r requirements.txt

En .env se necesitan estos valores. Notar que depende el modelo que elegimos podemos intercambiar:

#Gemini (required if any role uses provider="gemini") ---
GEMINI_API_KEY=your_gemini_api_key_here
GEMINI_MODEL_ID=gemini-2.5-flash
#Ollama (required if any role uses provider="ollama") ---
OLLAMA_HOST=http://localhost:11434
OLLAMA_MODEL_ID=gemma4:e2b-it-qat
#Per-role provider overrides (optional) ---
#Values: "gemini" or "ollama". Defaults are set in src/config.py.
MODEL_PROVIDER_COORDINATOR=ollama
MODEL_PROVIDER_EXTRACTOR=ollama
MODEL_PROVIDER_AGGREGATOR=ollama
MODEL_PROVIDER_VALIDATOR=ollama
MODEL_PROVIDER_PUBLISHER=ollama

cp .env.example .env

En src/config.py está la configuración de despliegue, en este caso de ejecución local se encuentran parámetros como la temperature, top_p, max_output_tokens (muy importante porque limita los tokens que pueden gastar los agentes).

Las constantes estructurales del grafo a nivel módulo, se encuentran en src/graph/builder.py :

NUM_EXTRACTORS → cantidad de nodos extractores paralelos (y de chunks que pide el Coordinator). Cambiarlo requiere que coincida con el num_chunks pasado a create_coordinator_agent().
MAX_NODE_EXECUTIONS → límite global de ejecuciones de nodos en todo el grafo, la salvaguarda contra el feedback loop infinito Validator↔Aggregator.
EXECUTION_TIMEOUT_SECONDS → timeout global del grafo completo.

NUM_EXTRACTORS = 3
MAX_NODE_EXECUTIONS = 15
EXECUTION_TIMEOUT_SECONDS = 1200 # (For local execution, it's advisable to have a high value)

Las pruebas están organizadas en tests/ en un solo nivel: ejecución rápida y determinista. Validan la lógica de las funciones de condición de Graph (needs_revision, is_approved, all_dependencies_complete), el parsing/validación de schemas (Relation, KnowledgeGraph, ValidatorOutput).
Se testea, además de los posibles errores del runtime, la resolución de provider/modelo por rol de src/config.py:

_resolve_provider() — que cada rol (coordinator, extractor, aggregator, validator, publisher) resuelva al provider correcto: el default (ROLE_PROVIDER_DEFAULTS) cuando no hay override, y la variable de entorno (MODEL_PROVIDER_VALIDATOR=ollama, etc.) cuando sí la hay.
get_model() — que devuelva una instancia de OllamaModel cuando el provider es "ollama", y GeminiModel cuando es "gemini".

python -m pytest

Procedemos a ejecutar el Graph principal. En examples/sample_input.txtestá el input de ejemplo.
Se puede ejecutar contra el modelo ollama local o vía api de gemini comentado más arriba.

python -m src.main

El log de las llamadas entre el pipeline de agentes se visualiza en la carpeta logs/. Contiene la data cruda que permite comparar comportamiento del modelo (cuántos turnos internos hace cada uno, cuánto tarda, si usa tool calls, etc.).

El resultado final
Es un Knowledge graph y se guarda en un .json enoutputs/.
Se visualiza la representación estructurada del texto de entrada, describiendo: qué conceptos existen (entities) y cómo se relacionan entre sí (relations), en formato sujeto-predicado-objeto.

Por último, hacemos una evaluación de pruebas sobre el grafo multiagente real con el concepto de "Evals". Esto es importante para todos los agentes futuros que construyas, tomar la documentación de Strands y descubrir cómo y para qué tenemos que evaluar nuestros agentes. El resultado se guarda en outputs/eval_report.json (el detalle de las evaluaciones están en "Conceptos Claves"):

python  -m  evals.evaluate_graph

📝 Nota: La explicación del código fuente y paso a paso de la ejecución se encuentra detallado en el README.md en el repositorio de github .

Conclusiones y lecciones aprendidas

Construir este pipeline con Graph me dejó varias lecciones que van más allá de la forma de crearlo según su documentación:

Las constantes estructurales del grafo no son de uso de común para todos los modelos. NUM_EXTRACTORS, MAX_NODE_EXECUTIONS y EXECUTION_TIMEOUT_SECONDS en builder.py parecen valores de infraestructura, pero en la práctica están acoplados al comportamiento del modelo elegido. Con Gemma4 local, el cuello de botella fue el tiempo (EXECUTION_TIMEOUT_SECONDS tuvo que subir a 1800s). Con Gemini, el cuello de botella fue la convergencia del feedback loop: con temperature=0.3 y top_p=0.9 el Aggregator regeneraba las triples con variación de wording en cada ronda, y el Validator nunca encontraba dos corridas iguales para aprobar, agotando MAX_NODE_EXECUTIONS sin converger. Solución: bajar a temperature=0 y top_p=0.5 .
Análisis del input propagation de Graph Un nodo sólo recibe el resultado de sus dependencias directas + el input original con el que comienza el grafo. El Publisher, dependiendo solo del Validator, se quedó sin las triples reales porque el Validator fue instruido a responder con una confirmación corta, no a repetir los datos. La solución fue agregar aggregator → publisher como dependencia adicional. Hay que diseñar edges, pensando qué datos necesita cada nodo, no solo qué controla el flujo.
Las semánticas OR de Python son una fuente de bugs silenciosos. Sin all_dependencies_complete(), el Aggregator se hubiera ejecutado 3 veces (una por extractor) en lugar de una vez con los 3 resultados completos. Cualquier nodo con múltiples edges de entrada en Python necesita esta verificación explícita si queremos esperar a todas las dependencias.
La granularidad de extracción es responsabilidad del prompt, no del framework. Ver entidades compuestas como "entities and relations" en lugar de dos nodos separados es variabilidad normal de un LLM con temperatura > 0. Hay que reforzar reglas en el prompt del Extractor y del Aggregator.
structured_output_model requiere que el modelo soporte tool calling (este parámetro se pasa en la creación del Agent. Hay que verificarlo (ollama show <model> → Capabilities: tools) antes de asumir que cualquier modelo local lo soporta.
Exact-match y LLM-as-judge miden cosas distintas. En una corrida, el mismo caso obtuvo F1 exact-match = 0.0 pero SemanticCorrectnessEvaluator = 1.0, el pipeline había extraído el 100% del conocimiento correcto, solo con sinónimos distintos ("Aggregator node" vs "Aggregator"). Confiar solo en exact-match hubiera hecho pensar que el pipeline falló por completo.

Recursos

Curso Fundamentos
Building AI Agent Harnesses with Strands Agents
Building AI Agent Harnesses – Video Course
Documentación Strands Agents
Graph
Evals
Otros
Multi-Agent Systems with Graph Pattern
Inyección de prompts en agentes de IA
5 Multi-Agent Patterns in Strands

Swarm en Strands: orquestación autónoma mediante handoffs emergentes

Laura Bolaños — Mon, 03 Aug 2026 14:55:38 +0000

Siguiendo con la serie de artículos sobre la orquestación de multiagentes en Strands, en estas notas le toca turno a Swarm o Enjambre explicado con un ejemplo gamificado de cinco agentes especializados, donde cada uno es responsable de diseñar una dimensión distinta de un videojuego. Testeado de dos maneras con Gemma4 + Ollama y con la api de Gemini.

Introducción

Para desarrollar y comprender agentes con el framework Strands Agents te propongo hacer un curso de fundamentos o leer su documentación (que es extensa). Los fundamentos son importantes! Es primordial conocer cómo dar complejidad a nuestros agentes, no esperar delegar toda la responsabilidad del diseño a la IA (recursos al pie de estas notas).
Para la prueba de concepto utilicé dos opciones locales de ejecución que me permitió analizar sus resultados:

Ollama + el pequeño modelo gemma4:e2b-it-qat (que pesa poco mas de 4gb) ejecutando en Docker.
Con la Api de gemini. La api key se puede generar de manera gratuita y utilizar el modelo "Gemini 2.5 Flash"

🎮 El caso de uso que tomé para desarrollar el patrón Swarm es la creación de un Game Design Document (GDD) a partir de una premisa: "roguelike de cocina en un castillo maldito..."
Participan cinco agentes especializados, cada uno responsable de una dimensión diferente del diseño del videojuego: mecánicas, narrativa, niveles, lore (historias, mitos, reglas, datos del pasado) y experiencia de juego. Todos colaboran para transformar una premisa simple en un Game Design Document (GDD) coherente.

A diferencia de un pipeline lineal, los agentes pueden detectar fricciones entre sus decisiones (una mecánica que contradice la narrativa, una regla de lore que rompe el balance) y reabrir la conversación con el agente correspondiente hasta llegar a un resultado consensuado.

Conceptos Clave

➡ Swarm es un patrón de orquestación de agentes colaborativo, donde múltiples agentes trabajan juntos como un equipo para resolver tareas complejas. A diferencia de los sistemas multiagente tradicionales, ya sean secuenciales o jerárquicos, un enjambre permite la coordinación autónoma entre agentes con contexto y memoria de trabajo compartidos.

Swarm es apropiado cuando:

La secuencia de pasos no se puede predefinir: de antemano no sabés qué agente necesitará intervenir, porque depende del contenido que se vaya generando.
Puede haber correcciones o retrocesos: el problema requiere ciclos de ida y vuelta entre especialistas (ejemplo: una decisión de un agente invalida el trabajo de otro).
Hay múltiples dimensiones de expertise en tensión: cada agente defiende una perspectiva distinta y el valor está justamente en que negocien entre sí, no en que trabajen aislados uno de otro.
Se necesita razonamiento colectivo emergente: la solución final surge de la interacción entre agentes, no de que un solo agente (o un humano) coordine todo desde arriba.

❗ No es el patrón ideal cuando el flujo de trabajo es fijo y predecible.

➡ Memoria / Contexto
Poseen memoria de trabajo compartida y contexto completo. Cuando el enjambre se ejecuta, el historial completo de mensajes (propuestas, objeciones y razonamientos de de los agentes anteriores) se transmite al nuevo agente que toma el control (handoff).
Payload del Handoff: además del historial acumulado, cuando un agente ejecuta la herramienta de handoff, puede adjuntar un mensaje o nota explícita (message / context) explicando por qué le transfiere la tarea y qué espera que haga.

➡ Nodos vs. Agentes
En Swarm, cada agente se registra como un "nodo" (SwarmNode) que envuelve al Agent. Esta distinción importa porque el swarm no razona en términos de "quién es quién" sino de "qué nodo ejecuta a continuación". El resultado final expone esto como node_history, una lista de nodos ejecutados, no una conversación: es lo que permite reconstruir después la topología real que se ejecutó, sin haberla tenido que diseñar de antemano.

➡ El mecanismo de Handoff es tool-calling, no un cambio de contexto mágico
Vale la pena aclarar explícitamente que handoff_to_agentno es una función especial del framework fuera del paradigma de LLMs: es una tool más, inyectada automáticamente por Strands en cada agente del swarm, con el mismo mecanismo de function-calling que cualquier otra tool. La consecuente es la fiabilidad del patrón Swarm depende enteramente de qué tan bien el modelo subyacente hace tool-calling. No es una limitación de Strands, es una dependencia estructural del patrón. Por eso, acompañando este artículo el caso de uso se testeo de dos maneras: con el pequeño modelo Gemma4 y con el modelo Gemini 2.5 Flash.

➡ Topología emergente vs. predefinida (el argumento central de "por qué Swarm")
En Swarm, la topología es un resultado, no una entrada. Se descubre recién en la ejecución, y puede variar entre corridas con la misma premisa (ejemplo: tengo 5 agentes y sólo intervienen 4). Esto es una ventaja de adaptabilidad y un riesgo no-determinista al mismo tiempo.
Se necesita indicar donde comienza el enjambre y cada punto de decisión lo toma el propio agente en base al contexto acumulado. Aquí un topología de ejemplo del caso de uso:

mechanic_designer
      ↓
level_architect ←──────────┐
      ↓                    │
playtest_simulator ─────────┤ (iteration 1: objection → adjustment)
      ↓                    │
level_architect ──────────→┘
      ↓
playtest_simulator ─────────┐ (iteration 2: objection → adjustment)
      ↓                    │
level_architect ←───────────┘
      ↓
narrative_weaver
      ↓
lore_keeper
      ↓
playtest_simulator ─────────┐ (iteration 1: objection → adjustment)
      ↓                    │
level_architect ←───────────┘
      ↓
playtest_simulator
      ↓
[VERDICT: NO FRICTION DETECTED] → END

➡ Guardrails como parte del diseño
max_handoffs: Máximo de transferencias entre agentes permitidos en todo el swarm antes de forzar el corte. Es el límite global de "pasos" de la ejecución completa.
max_iterations: Máximo de iteraciones del swarm (ejecuciones de nodo) permitidas. En la práctica actúa junto con max_handoffs como segunda red de seguridad contra ejecuciones descontroladas.
execution_timeout: Tiempo total en segundos que puede durar la ejecución completa del swarm, sumando todos los agentes y handoffs. Si se supera, el swarm corta con Status.FAILED aunque esté en medio de un turno.
node_timeout: Tiempo máximo (en segundos) que un agente individual puede tardar en un solo turno (una llamada al modelo + su respuesta). Protege contra que un nodo puntual se cuelgue sin afectar el límite global.
repetitive_handoff_detection_window: Tamaño de la "ventana" (cantidad de handoffs recientes) que Strands analiza para detectar patrones repetitivos. Con 6, mira los últimos 6 handoffs para decidir si hay un loop.
min_unique_agents: Dentro de esa ventana, cantidad mínima de agentes distintos que deben haber participado para considerar el flujo "sano". Si en los últimos 6 handoffs participaron menos de 3 agentes únicos (ej. solo 2 rebotando entre sí), Strands lo detecta como ping-pong y corta el swarm.
Todos los guardrails anteriores no son opcionales para un swarm en producción, son necesarios para limitar la autonomía de los agentes y que el costo de tokens, tiempo o dinero en APIs pagas no se descontrole.

➡ La importancia del diseño de prompts
Strands provee el mecanismo de handoff (la tool, el hook, los guardrails), pero no decide cuándo usarlo, eso está en el system prompt de cada agente. En este caso de uso, cada uno de los 5 prompts define explícitamente tres cosas: el rol y criterios de evaluación del agente, a quién y bajo qué condición debe transferir el control, y reglas de convergencia para evitar que vuelva a objetar lo mismo una vez resuelto ("Convergence rule").

Esta última fue necesaria escribirla ya que en las primeras ejecuciones algunos agentes re-abrían el mismo desacuerdo varias veces con distintas palabras, generando ciclos improductivos que ni los guardrails ni el hook podían distinguir de una negociación legítima. La solución fue de prompt, instruir explícitamente a cada agente a aceptar una corrección después de la primera vuelta, salvo que aparezca un motivo nuevo. Los guardrails protegen contra loops estructurales; esto resuelve los loops semánticos.

➡ Hooks como punto de extensión para mitigar limitaciones del modelo elegido
Strands permite engancharse al ciclo de ejecución del agente mediante hooks, interceptando eventos como una llamada a herramienta exitosa. En el caso de uso se implementó StopAfterHandoffHook, que fuerza al agente a detener su turno inmediatamente después de un handoff exitoso.

Este mecanismos sirve para cuando el prompt no alcanza para garantizar un comportamiento, evita que el modelo llame a la herramienta de handoff más de una vez por turno. Es una intervención determinista a nivel de código, sin depender del prompt engineering.

➡ Evaluaciones (Evals)
Existe el package strands-agents-evals que provee evaluadores reutilizables (por salida, por trayectoria de tool-calls, por trazas de ejecución, etc). En este caso de uso se implementaron dos evaluadores:
- Evaluación por Trayectoria (Trajectory Evaluation). En vez de exigir una secuencia exacta de handoffs, valida propiedades estructurales de la ejecución.

que el punto de entrada haya sido el correcto.
que haya participado una cantidad mínima de agentes únicos, y que los agentes indispensables (como mechanic_designer) hayan intervenido.

- Evaluación por Salida (Output Evaluation). Verifica que el GDD final contenga las palabras clave esperadas del dominio del juego (ej. "curse", "ingredient", "castle"), como chequeo básico de que el contenido generado es relevante a la premisa de origen.

⭐ Este enfoque refleja una diferencia clave frente a patrones más deterministas como agents-as-tools donde se puede evaluar contra un resultado esperado preciso (si se delegó al agente correcto); en cambio en Swarm hay que evaluar la forma del comportamiento, no una secuencia fija.

Descripción de la solución

📦 Repositorio GitHub: github.com/reinalau/strands-swarm

Como comenté más arriba, utilicé 2 opciones de modelos para la ejecución y analizar el comportamiento, pero podes usar solo una de ellas:

a. Docker Desktop, luego descargué la imagen de Ollama e instalé gemma4:e2b-it-qat (que pesa poco mas de 4GB). Todos los modelos gemma los podés encontrar aquí

# Start the Ollama server with a persistent volume
docker run -d --name ollama -p 11434:11434 -v ollama_data:/root/.ollama ollama/ollama

# Download the model
docker exec -it ollama ollama pull gemma4:e2b-it-qat

# Test that the model responds
docker exec -it ollama ollama run gemma4:e2b-it-qat

# Verify that the model is running
docker exec -it ollama ollama ps

b. Generé una api key de gemini de capa gratuita, desde aquí. Te permite usar el modelo Gemini 2.5 Flash.

El código del multiagente está en Python y la estructura del proyecto se diseñó de manera que sea más explicativo su lógica:

strands-swarm/
├── README.md
├── requirements.txt
├── .env.example
├── .gitignore
│
├── src/
│   ├── __init__.py
│   ├── main.py                  # entry point, builds and runs the swarm
│   ├── config.py                # model provider config, timeouts, swarm limits
│   │
│   ├── agents/
│   │   ├── __init__.py
│   │   ├── _common.py           # shared model factory + prompt loader
│   │   ├── _hooks.py            # StopAfterHandoffHook
│   │   ├── mechanic_designer.py
│   │   ├── narrative_weaver.py
│   │   ├── level_architect.py
│   │   ├── lore_keeper.py
│   │   └── playtest_simulator.py
│   │
│   ├── prompts/
│   │   ├── mechanic_designer.md
│   │   ├── narrative_weaver.md
│   │   ├── level_architect.md
│   │   ├── lore_keeper.md
│   │   └── playtest_simulator.md
│   │
│   ├── swarm/
│   │   ├── __init__.py
│   │   └── build_swarm.py       # instantiates agents + configures Swarm (max_handoffs, etc.)
│   │
│   └── output/
│       ├── __init__.py
│       └── gdd_builder.py       # consolidates node_history/results into the final GDD
│
├── evals/
│   ├── __init__.py
│   ├── eval_cases.py            # EvalCase definitions (premise, expected agents, keywords)
│   └── run_evals.py             # trajectory + output evaluators over the swarm
│
├── examples/
│   └── example_premise.txt      # "cooking roguelike in a cursed castle"
│
├── outputs/
│   └── .gitkeep                 # generated GDDs land here after each run
│
├── logs/
│   └── .gitkeep                 # execution logs / handoff events
│
└── tests/
    ├── __init__.py
    └── test_swarm_flow.py

Ejecución Local

Una vez que tenemos el repositorio del código fuente clonado y el docker de ollama con el modelo gemma 4 o la api key de gemini generada, pasamos armar el ambiente.
Los requerimientos que vamos a encontrar en requirements.txt:
strands-agents[ollama]
strands-agents[gemini]
strands-agents-evals
python-dotenv
pytest

pip install -r requirements.txt

En .env necesitamos:
OLLAMA_HOST=http://localhost:11434
MODEL_NAME=gemma4:e2b-it-qat
MODEL_PROVIDER=gemini # ollama
GEMINI_API_KEY=tuapikeyOpcional
GEMINI_MODEL_NAME=gemini-2.5-flash
LOG_LEVEL=INFO
MODEL_TEMPERATURE=0.5
MODEL_MAX_TOKENS=3500
MODEL_NUM_CTX=4096
MAX_HANDOFFS=12
MAX_ITERATIONS=12
EXECUTION_TIMEOUT=5000
NODE_TIMEOUT=1500
REPETITIVE_HANDOFF_DETECTION_WINDOW=6
REPETITIVE_HANDOFF_MIN_UNIQUE_AGENTS=3
ENTRY_POINT_AGENT=mechanic_designer
LOG_DIR=logs
OUTPUT_DIR=outputs

   cp .env.example .env

Las pruebas están organizadas en un enfoque de 2 niveles (tests/):
Nivel 1 (Rápidas y deterministas): Valida la estructura del swarm, la configuración de nodos/límites, la extracción de texto y la consolidación del GDD sin realizar llamadas reales al modelo. Usa cadenas simuladas como "Cooking roguelike in a cursed castle." o "Test Premise".

   python -m pytest

Nivel 2 (Test de integración end-to-end): Ejecuta el swarm completo contra el modelo real (Gemma4 en Ollama o Gemini). Está deshabilitado por default, pytest lo salta automáticamente, y se activa así en esta ejecución:

   RUN_INTEGRATION_TESTS=1 python -m pytest -m integration

📝 Nota: el comportamiento de activación/desactivación explícita para tests que dependen de un LLM real es una práctica común cuando se integran estos flujos a pipelines de CI/CD, donde ejecutar llamadas reales a un modelo en cada commit sería muy lento.

Procedemos a ejecutar el Swarm principal. Se puede ejecutar contra el modelo ollama local o vía api de gemini. Se configura en .env , tener en cuenta de cambiar MODEL_PROVIDER a "gemini" u "ollama". También recomiendo revisar valores default de src/config.py.

python -m src.main

El log de las llamadas entre agentes se visualiza en la carpeta logs/.
El resultado final del intercambio de mensajes entre los agentes del enjambre es el Game Design Document y se guarda en un documento markdown en la carpeta outputs/.

⭐ Te invito analizar la topología de handoffs después de las ejecuciones para entender si los agentes necesitan ajustes ya sea de prompts, hooks o parámetros de configuración.

Por último, hacemos una evaluación de pruebas sobre el agente real con el concepto de "Evals". Esto es importante para todos los agentes futuros que construyas, tomar la documentación de Strands y descubrir cómo y para qué tenemos que evaluar nuestros agentes.
Se desactiva el recolector de telemetría OpenTelemetry: OTEL_SDK_DISABLED=true para evitar cuelgues en un entorno local con el modelo en ollama (si internamente no alcanza un endpoint se cuelga indefinidamente).

export OTEL_SDK_DISABLED="true"
python -m evals.run_evals

📝 Nota-2: La explicación del código y paso a paso de la ejecución se encuentra detallado en el README.md en el repositorio de github.

Conclusiones

El patrón *Swarm * cede el control del flujo al propio modelo. Una corrida puede resolverse en 4 pasos o en 11, en un minuto o en dos horas, según decisiones que toman los agentes que intervienen.
Con un modelo chico experimenté loops de handoff, ping-pong entre agentes, transferencias narradas en texto en lugar de ejecutadas y para resolverlo tuve que agregar controles explícitos: límites de iteración, detección de repetición y un hook que corta el turno apenas el handoff se confirma.
La autonomía de un swarm no reemplaza los guardarraíles de ingeniería, los vuelve indispensables.

⭐ Y como trabajo futuro hay que pensar cómo implementar un proyecto multiagente Swarm productivo. El presente proyecto es educativo y sirve para entender el funcionamiento del patrón, pero es insuficiente para producción. AWS ya tiene un camino natural para eso: Amazon Bedrock AgentCore, un runtime serverless que ejecuta agentes Strands con aislamiento por sesión, observabilidad, memoria administrada y escalado automático. Queda para un próximo artículo explorar esa migración.

Recursos

Curso Fundamentos
Building AI Agent Harnesses with Strands Agents
Building AI Agent Harnesses – Video Course
Documentación Strands Agents
Swarm
Evals
Otros
Blog Writer Agent using Swarm Pattern
Building AI Agent Harnesses – Video Course
Detener alucinaciones de agentes de IA

Agents as Tools en Strands: orquestación jerárquica en local con Gemma 4 y Ollama

Laura Bolaños — Mon, 27 Jul 2026 16:33:25 +0000

Hace tiempo vengo consumiendo cursos de orquestación de agentes de distintos frameworks y me propuse navegar por los diferentes patrones de Strands Agents de complejidad media, ejecutados localmente (con la idea de encarar más adelante el deploy en AWS). Este artículo está dedicado a Agents-as-Tools, corriendo con Ollama en una laptop con solo 16GB de RAM 💻.

Introducción

Para que la prueba de concepto se pueda ejecutar localmente, utilicé Ollama + el pequeño modelo gemma4:e2b-it-qat (que pesa poco mas de 4gb) ejecutando en Docker.

El caso de uso que tomé para desarrollar el patrón es la automatización del soporte básico de TI:
🛠 Se recibe un ticket de soporte y se determina si es un ticket de facturación, técnico o seguridad. Luego se envía al agente especializado para que lo resuelva.

Conceptos claves

➡ Agents As Tools es un patrón de orquestación multiagente que como se describe en la documentación es jerárquico (hub and spooke), donde un orquestador delega tareas a agentes especializados que tienen diferentes tools para resolver. El orquestador y cada agente poseen contexto aislado, no se contaminan entre sí.

Para clarificar el funcionamiento: al delegar, hay dos agents loops anidados, no uno compartido: el orquestador no "pausa" su razonamiento en espera del especialista, simplemente visualiza una tool call que devuelve texto, por detrás, esa tool call disparó un loop completo e independiente que ya terminó antes de volver.

Orchestrator loop
   └─ calls billing_agent(query) → triggers a new, isolated loop
         └─ Billing loop: check_invoice_status → process_refund → final response
   ← receives only the final string (doesn't see the internal tool calls)
   └─ continues its own loop: delegates to another specialist or replies to the user

➡ @tool no distingue entre operación simple o integración vía APis y agente completo , el patrón Agents-as-Tools explota que un agente cumpla la misma interfaz que una tool (recibe input, devuelve output), para que se pueda componer recursivamente. Es lo que permite anidar agentes dentro de agentes sin que el nivel superior necesite saber la complejidad interna del nivel inferior.

⭐ La descripción (docstring) de cada función @tool no es un comentario decorativo: es el input que el LLM orquestador lee en tiempo de ejecución para decidir a qué especialista delegar. Distinto del parámetro description= del propio Agent, que es metadata informativa y no interviene en el routing.

➡ Memoria del orquestador (ConversationManager). Utilicé el concepto de compresión al hacer que el agente recuerde los últimos 10 mensajes o tickets de la sesión para mantener contexto entre interacciones consecutivas con SlidingWindowConversationManager(window_size=10)
Mantiene los mensajes en una lista dentro del objeto Python en RAM durante la ejecución del proceso.

➡ Hook de dominio (SteeringHandler). Implementa el "HookProvider" de Strands, en este caso de uso fuerza el orden de pasos del protocolo de respuesta ante incidentes de Seguridad. Si el LLM intenta llamar por ejemplo a revoke_access_token sin haber auditado primero la IP, el hook lo bloquea con event.cancel_tool antes de que la función se ejecute. El framework impone la lógica de negocio determinista, sin depender del criterio del modelo. Describe con precisión los tres eventos BeforeInvocationEvent, AfterToolCallEvent, BeforeToolCallEvent

Los hooks sirven en general para:

Prevenir loops infinitos o excesivos de tool calls (control de costos/tokens)
Guardrails de seguridad/negocio (ej. no permitir más de n transacciones, n consultas a una API con rate limit, etc.)
Es el mecanismo estándar de Strands para inyectar lógica de control sin modificar el core del agent loop.

➡ Evaluaciones (Evals): evaluación de comportamiento del agente (con Contains, no asserts tradicionales).

Algunas consideraciones que tomé para poder ejecutar los evals sin que se cuelguen en un entorno local con el modelo en ollama: Desactivé OTLP de Opentelemetry, este si internamente no alcanza un endpoint (localhost:4318) se cuelga indefinidamente.

En el caso de uso del repositorio se hacen evaluaciones deterministas ya que se utiliza solo un LLM, no se abarcan todas las evaluaciones pero sí dos importantes descritas debajo.

Output Evaluation. Evalúa el resultado final (el texto que recibe el usuario), sin importar el camino interno que tomó el agente para llegar ahí. Es un chequeo determinista de keyword matching: la respuesta debe contener ciertas palabras clave esperadas (INV-1002, USR-884, etc.).

Trajectory Evaluation. No evalúa qué respondió el agente, sino cómo llegó ahí, qué tools/sub-agentes invocó durante su razonamiento. En el código, extract_called_tools() inspecciona agent.messages buscando bloques toolUse, y evaluate_trajectory() verifica que el sub-agente esperado (ej. BillingAgent) haya sido efectivamente el delegado. Para la ejecución en entorno local con Ollama, la función extract_called_tools extrae directamente los nombres de las herramientas en agent.messages y comprueba en milisegundos si se invocó a case.expected_agent, sin necesidad de instanciar un modelo juez adicional ni hacer peticiones extra a Bedrock/Ollama (sin cuelgues asíncronos).

⭐ PASS / FAIL a nivel dimensión, en el output: cada EvalCase se marca como aprobado (case_passed) solo si ambas dimensiones pasan (traj_eval.test_pass and out_eval.test_pass). Un agente puede delegar al especialista correcto (trayectoria OK) pero responder sin las keywords esperadas (output FAIL), y el caso se marca como fallido igual. Una sola dimensión de evaluación no alcanza: el agente puede "hacer lo correcto" pero "comunicarlo mal", o viceversa.

Descripción de la solución

📦 Repositorio GitHub: github.com/reinalau/strands-agents-as-tools

Para alojar el LLM utilicé Docker Desktop, luego descargué la imagen de Ollama e instalé gemma4:e2b-it-qat (que pesa poco mas de 4GB). Todos los modelos gemma los podés encontrar aquí pero este en particular funciona OK en una laptop con 16GB de RAM.

Como condición necesaria asegurate de dar memoria suficiente a Docker.

# Start the Ollama server with a persistent volume
docker run -d --name ollama -p 11434:11434 -v ollama_data:/root/.ollama ollama/ollama
# Download the model
docker exec -it ollama ollama pull gemma4:e2b-it-qat
# Test that the model responds
docker exec -it ollama ollama run gemma4:e2b-it-qat
# Verify that the model is running
docker exec -it ollama ollama ps

Importante! Testear el modelo gemma 4 en la terminal haciendo alguna pregunta para corroborar que responda.

El código del multiagente está en Python y la estructura del proyecto se diseñó de manera que sea más explicativo su lógica:

strands-agents-as-tools
├── README.md
├── requirements.txt
├── .env.example
├── .gitignore
│
├── src/
│   ├── __init__.py
│   ├── main.py
│   ├── config.py
│   │
│   ├── agents/
│   │   ├── __init__.py
│   │   ├── orchestrator.py
│   │   ├── billing_agent.py
│   │   ├── technical_agent.py
│   │   └── security_agent.py
│   │
│   ├── tools/
│   │   ├── __init__.py
│   │   ├── billing_tools.py
│   │   ├── technical_tools.py
│   │   └── security_tools.py
│   │
│   └── hooks/
│       ├── __init__.py
│       └── security_verification_hook.py   # Domain SteeringHandler
│
├── examples/
│   └── sample_tickets.py
│
├── evals/
│   ├── __init__.py
│   ├── eval_cases.py                 # Cases with inputs, expected agent and keywords
│   └── run_evals.py                  # Dual evaluator: Trajectory (Tool Call) + Output (Keywords)
│
└── tests/
    └── test_agents.py                # Unit tests for tools (no LLM)

Ejecución local

Una vez que tenemos el repositorio del código fuente clonado y el docker de ollama con el modelo gemma 4 ejecutando, pasamos armar el ambiente.

Los requerimientos que vamos a encontrar en requirements.txt:
strands-agents
strands-agents-evals
ollama
python-dotenv
pytest

pip install -r requirements.txt

En el .env vamos a necesitar:
OLLAMA_HOST=http://localhost:11434
MODEL_NAME=gemma4:e2b-it-qat
LOG_LEVEL=INFO

cp .env.example .env

Los test son pruebas unitarias deterministas (tests/). Permite validar rápidamente y de forma aislada la lógica de código puro de las herramientas (tools) de negocio (facturación, soporte técnico y seguridad), sin requerir inferencia de LLM. Garantizan que las funciones auxiliares retornen los estados y formatos esperados antes de ser expuestas como capacidades @tool al sistema multiagente.

python -m pytest tests/

Procedemos a ejecutar el flujo principal demostrativo donde se ve al orquestador delegar tickets a los especialistas procesados por Ollama. Puede ser algo lento debido al modelo de ollama elegido pero finalmente termina el flujo con los ejemplos de tickets. Se utilizan ejemplos de soportes dentro de main con from examples.sample_tickets import SAMPLE_TICKETS ...te invito a cambiarlos!

python -m src.main

Por último, hacemos una evaluación de pruebas de calidad y precisión ejecutadas sobre el agente real con el concepto de "Evals". Esto es importante para todos los agentes futuros que construyas: hay que tomar la documentación de Strands y descubrir cómo y para qué tenemos que evaluar nuestros agentes.

También recomiendo establecer OTEL_SDK_DISABLED=true para desactivar el recolector de telemetría OpenTelemetry (explicado en Conceptos Claves)

export OTEL_SDK_DISABLED="true"
python -m evals.run_evals

Este último script ejecuta dos metodologías de evaluación según las especificaciones de Strands Agents: Output / Keyword Evaluation y Tool-Call Trajectory Evaluation (explicado en Conceptos Claves)

📝 Nota: Todo la explicación del código del repositorio y paso a paso de la ejecución se encuentra en el README.md

Conclusiones

Implementar Agents-as-Tools con un modelo local vía Ollama fue una buena forma de entender el patrón de orquestación sin gastar, pero también descubrí que modelos chicos como gemma4:e2b-it-qat pueden ser inconsistentes en su razonamiento (llamadas duplicadas a una misma tool, dudas antes de delegar) a diferencia de un modelo más grande (Bedrock/Claude/GPT-4) que probablemente sea más preciso. Esto no invalida el patrón, todo lo contrario: reafirma por qué los guardrails deterministas (el hook de seguridad) y las evaluaciones automáticas es la forma de detectar el comportamiento errático antes de que llegue a producción.

Limitaciones del ejemplo

Este repositorio es educativo, y tiene varias simplificaciones:

Tools hardcodeadas con datos mock: check_invoice_status, check_system_status, audit_ip_address, etc. devuelven datos fijos en el código, no consultan ningún sistema real.
Un solo LLM local: no se probó el comportamiento con otros modelos para comparar consistencia de routing/tool-calling entre modelos de distinto tamaño.
Evaluación: solo se cubrieron Output y Trajectory de forma determinista; no se probó chaos testing, LLM-as-judge, ni simulación multi-turno (mirar la documentación oficial).

Pensando en este mismo Multiagente productivo 🤯

Conectar tools a APIs/sistemas reales: reemplazar los mocks por llamadas a una API de facturación real, un endpoint de status de infraestructura (ej. AWS CloudWatch, Datadog), y un servicio real de gestión de identidad (ej. IAM, Okta) para revocación de tokens. Varios de estos ya existen como servidores MCP mantenidos por la comunidad/AWS (conectarlos vía MCPClient sería más rápido que escribir cada tool a mano).
Persistencia real de sesión: en este ejemplo cada ticket es stateless entre ejecuciones de main.py; sumar un SessionManager(FileSessionManagero DynamoDBSessionManager) para simular conversaciones multi-turno reales de un mismo usuario.
Comparar modelos: correr el mismo test suite contra un modelo de Bedrock o la API de Anthropic, y comparar tasa de errores de routing/tool-calling contra el modelo local, cuantificar el trade-off costo/latencia vs. confiabilidad.
Chaos testing: simular caídas de las APIs reales (una vez conectadas) con ChaosPlugin, para validar que el agente degrada con gracia en vez de alucinar una respuesta.

⭐ Migrar a Bedrock AgentCore: envolver el orquestador con BedrockAgentCoreApppara exponerlo vía el runtime administrado de AWS, adicionando AgentCoreMemorySessionManagerpara memoria semántica de usuario (facts/preferences) en vez de solo SlidingWindowConversationManager

Recursos

Cursos Fundamentos
Building AI Agent Harnesses with Strands Agents
Building AI Agent Harnesses – Video Course
Documentación Strands Agents
Agents as Tools
Trajectory Evaluator
Artículos de Builders y AWS Developer Advocate
AWS Strands Agents: simplifica la creación de agentes de IA
Detener alucinaciones de agentes de IA

Apuntes para la certificación AWS CloudOps Engineer Associate (SOA-C03) - Parte 2

Laura Bolaños — Thu, 04 Jun 2026 13:41:05 +0000

Segunda parte de las notas de examen. La idea es que identifiques los principales temas para el examen de certificación y conocer algunos tips de estudio para alcanzar con éxito tu meta 🎓

⬅ Apuntes para la certificación AWS CloudOps Engineer Associate (SOA-C03) - Parte 1

Temas que son claves conocer para el examen - Segunda Parte

AWS Config

Es prioritario revisar todas sus casos de uso y su integración con acciones de remediación con SSM y sus runbook. La remediación puede ser manual o automática.

La integración importante es con EventBridge para realizar una acción. Algo a saber es que los avisos a un equipo de soporte se hacen a través de SNS.
Data Aggregation for AWS Config (Multi-Account - Multi-Region) ➡ recopila datos de configuración y cumplimiento de varias cuentas y varias regiones de AWS. Una organización en AWS Organizations y todas las cuentas de esa organización que tengan AWS Config habilitado.
Reglas de configuración comunes en AWS Config:

Rule	Qué chequea
`cloudtrail-enabled`	CloudTrail habilitado en la cuenta
`mfa-enabled-for-iam-console-access`	Los usuarios de IAM con acceso a la consola tienen MFA habilitado
`s3-bucket-public-read-prohibited`	Los buckets de S3 no permiten acceso de lectura pública
`encrypted-volumes`	Los volúmenes de EBS están encriptados
`rds-storage-encrypted`	Las instancias RDS tienen encriptación del storage habilitada
`iam-password-policy`	La política de contraseñas cumple con los requisitos especificados
`restricted-ssh`	Los Security Groups no permiten acceso SSH sin restricciones (puerto 22)
`root-account-mfa-enabled`	La cuenta root tiene MFA habilitado
`vpc-flow-logs-enabled`	VPC Flow Logs está activado
`cloud-trail-encryption-enabled`	Los logs de CloudTrail están encriptados con KMS
`s3-bucket-ssl-requests-only`	S3 solo acepta requests HTTPS
`ec2-instances-in-vpc`	Las instancias EC2 están dentro de una VPC
`access-keys-rotated`	Las access keys de IAM se rotan dentro de N días

Control Tower

Relacionado con casos de uso de Organization ➡ Proporciona una landing zone para múltiples cuentas. Automatiza la configuración de AWS Organizations, la venta de cuentas, las medidas de seguridad (controles preventivos y de detección) y un registro de auditoría centralizado.

Security Hub - WAF - Detective - Inspector - GuardDuty

Es útil realizar cuadro comparativo con los servicios Detective, Inspector y GuardDuty para visualizar sus diferencias y en qué casos de uso son más adecuados. La mayoría se utilizan para controles de detección.

Security Hub: gestiona la postura o posición de seguridad de una Organización. Automatiza las comprobaciones de mejores prácticas y agrega alertas de Seguridad.
WAF: los casos de uso referidos son sencillos de identificar, detección de ataques sql injection - bloqueo de ip de países-rate limiting por IP, etc. Se gestiona mediante Web ACLs con reglas propias o AWS Managed Rules (reglas preconfiguradas por AWS)
Inspector: Evalúa automáticamente vulnerabilidades en EC2, ECR y funciones Lambda ➡ prevención y detección proactiva.
Detective: simplifica el proceso de analizar, investigar e identificar la causa raíz de los hallazgos de seguridad o actividades sospechosas en las cuentas de AWS. Recopila registros de CloudTrail (frase clave es log de APIs), VPC Flows, GuardDuty, entre otros ➡ Actúa en el post-incidente.
GuardDuty: Detección de amenazas continua mediante análisis de CloudTrail, VPC Flow Logs y DNS logs. Usa ML para identificar comportamiento anómalo (ej: instancia EC2 haciendo crypto mining, credenciales filtradas usadas desde IP sospechosa). Es el detector en tiempo real, genera findings que pueden disparar acciones en EventBridge → Lambda/SNS.

Conceptos básicos de Networking

NACL: Actúan a nivel de subnet y no tienen estado. Hay que agregar reglas de entrada y de salida. Las reglas se evalúan de manera ascendente. Es el primer mecanismo de defensa a nivel subred, útil para bloquear IPs específicas. Ejemplo de resolución de problema: una instancia EC2 (en una private subnet) no tiene salida a internet? ➡ Las reglas de entrada y salida deben permitir el tráfico (incluidos los puertos de retorno efímeros 1024–65535).
Security groups: Actúan a nivel de instancia o servicio. Tienen estado, todo lo que se permite entrar- se permite salir (salvo que indiques lo contrario en las reglas de salida).
- Resolución de conexiones vía SSH o RDP a instancias EC2. Qué revisar? En principio las reglas de entrada del Security Group a los puertos correspondientes.
Nat Gateway: es escalable mejor que Instance Nat Gateway. Asociada a una subnet pública. Solo para IPV4. Asegurar que la Private subnet route table debe tener
Egress-Only Internet Gateway (EIGW): permite que los recursos en una subred privada se comuniquen con el exterior a través de IPv6

VPC FlowLogs

VPC > Your VPCs > Flow logs > Create Flow Logs (se necesita un rol para escribir en CloudWatch). Monitorea todo el trafico de la VPC determinada aparece en CloudWatch > Logs > Log Management .
Otros destinos de logs son S3 y Kinesis Data Firehose. Se puede realizar consultas sql mediante Athena tomando como fuente S3.
Conocer el formato de los registros Default VPC Flow Logs y Custom VPC Flow Log Format. Cómo configurar y qué soportes permite resolver.

Ejemplo cuando falta una regla en Nacl o Security Group para permitir una conexión:

2 123456789012 eni-abc123 10.0.1.4 10.0.2.5 43234 443 6 12 1400 1624387215 1624387275 ACCEPT OK

2 123456789012 eni-abc123 172.31.16.139 172.31.16.21 80 42333 6 24 2456 1624387215 1624387275 REJECT OK

Route 53

Hosted zone ➡ pública y privada. Comprender el concepto de casos de uso: El cliente externo consulta la zona pública de Route 53 y llega a la versión pública de la app y el cliente interno dentro de la VPC consulta la zona privada de Route 53 y llega a la versión interna de la app ➡ ambos pueden tener el mismo nombre laub.com pero devuelven destinos diferentes de acuerdo de donde se lo consulte.
Es primordial conocer los tipos de registros y casos de usos:

Tipo	Qué contiene	Uso
`A`	IPv4	www.laub.com → 52.10.1.100
`AAAA`	IPv6	www.laub.com → 2001:db8::1
`CNAME`	Otro hostname	www → otro.dominio.com
`Alias`	Recurso AWS	laub.com → mi-alb.us-east-1.elb.amazonaws.com
`NS`	Name servers de la zona	Delegación de subdominios
`SOA`	Metadatos de la zona	Se crea automático
`MX`	Servidor de correo	laub.com → mail.empresa.com
`TXT`	Texto libre	Verificación de dominio, SPF
`SRV`	Servicio + puerto	Usado por algunos protocolos
`PTR`	DNS inverso	IP → hostname

Route 53 Resolver: define cómo y hacia dónde se hacen las consultas DNS.
- En esta feature se da la relación de entornos híbridos, DNS de on-premises resuelto por Route 53 (Outbound endpoint) o un DNS en AWS (en VPC) que lo resuelve on-premises (Inbound endpoint).
Route 53 routing policies, hay preguntas de examen sobre estas features relacionados con estrategias de deployment o failover:

Política	Descripción	Health Checks	Caso de Uso
Simple	Un único servidor. Sin lógica ni failover.	No soporta	Un solo recurso sin redundancia
Weighted	Distribución de tráfico por pesos.	Soportado — si falla un destino su peso es ignorado	Deployment canary, A/B testing
Latency	Dirige el tráfico al recurso con menor latencia.	Soportado	Usuarios globales que necesitan baja latencia
Geolocation	Enruta según la ubicación geográfica del origen de la consulta DNS (continente, país o estado).	Soportado	Contenido regionalizado, cumplimiento normativo
Geoproximity	Enruta según ubicación geográfica de los recursos con valor de sesgo opcional. Requiere Route 53 Traffic Flow.	Soportado	Balanceo geográfico con control fino de fronteras
Failover	Enruta a recurso principal; si falla va al secundario. Recursos en VPC privada requieren CloudWatch Alarm como intermediario.	Requerido	Alta disponibilidad activo-pasivo
IP-Based	Enruta según la IP del remitente de la consulta DNS.	Soportado	Segmentación por ISP o rango de IPs corporativas
Multivalue Answer	Devuelve hasta 8 registros saludables al azar.	Soportado	Distribución simple sin necesidad de ELB
Cross Account	La zona padre delega un subdominio creando registros NS que apuntan a la zona hija en otra cuenta.	—	Gestión de DNS entre múltiples cuentas AWS

Query Logging: Registra todas las consultas DNS está disponible para zonas públicas., con esto podemos resolver problemas. Auditar consultas DNS de una zona privada ➡ no es Route 53 query logging, es Route 53 Resolver Query Logs (servicio diferente).
Tipos de Health checks: Es un concepto básico a retener ➡Endpoint health check, Calculated health check y CloudWatch alarm health check.

Cálculo de CIDR para un Subnet

En una VPC no se puede superponer el bloque de direcciones cidr de sus subnet ➡ ejemplo encontrar el tamaño mínimo de la subred que tenga 30 direcciones IP disponibles.

Total de direcciones IP disponibles = 2^(32-X) – 5 (Reservadas por AWS)

Donde X es la notación CIDR.

Para el bloque CIDR 192.168.1.0/26.

Total de direcciones IP disponibles = 2^(32-26) – 5 = 59 direcciones IP.

AWS Global Accelerator

Si enfrentas alguna pregunta que necesitas tiempos de milisegundos con direcciones IP anycast estáticas ➡ la respuesta seguramente es Global Accelerator.

Frases claves para este servicio: aceleración del tráfico TCP/UDP.

VPC Peering - Transit Gateway

VPC peering: Conocer las limitaciones de ➡ hasta 10 interconexiones de VPC es potable. No hay transitividad en las conexiones. Es conveniente realizar laboratorio para entender cómo se configuran las Route Tables. Tener presente que se puede realizar conexiones entre diferentes regiones y cuentas.
- Solucionar conexion de VPC Peering entre dos instancias de EC2 en dos VPC diferentes. Se configuró correctamente el VPC peering entre ambas. Una instancia A puede hacer ping a instancia B. Pero la instancia B no puede hacer ping a la instancia A ➡ Posiblemente para solucionar este problema es necesario actualizar el grupo de seguridad de la instancia A para permitir el tráfico ICMP entrante.
Transit Gateway: actúa como una hub de redes eliminando la necesidad de complejas redes de interconexión. A diferencia de VPC peering tiene ruteo transitivo. Importante! conocer el concepto de adjuntar una VPC (Attach a VPC).
- Soporta multicast.
- Se puede usar con VPN y Direct Connect como hub central, simplificando arquitecturas híbridas.
- TGW Route Tables permiten segmentar el tráfico entre VPCs conectadas.Ejemplo ➡ aislar producción de desarrollo.

Cloudfront

Comprender cómo configurar los diferentes orígenes. El más sencillo y natural que conocemos, si has rendido alguna certificación, es S3. Pero vas a tener que preparar ELB y el caso especial de EC2:

Origin Type	Description	Clave para el examen
Amazon S3	Contenido estático	OAC reemplaza OAI (legacy). Sin OAC, el bucket puede quedar público
Application Load Balancer	Contenido dinámico	El ELB debe ser público. CloudFront no puede llegar a un ALB interno. Usá security group del ALB restringido a los IPs de CloudFront para que el tráfico solo entre por CloudFront
EC2 instance	Servidores web custom	La instancia debe ser pública y con security group que permita IPs de CloudFront
API Gateway	REST o HTTP APIs	Podés deshabilitar el endpoint público de APIGW y forzar acceso solo vía CloudFront
Custom HTTP origin	Servidores on-premise u otros	Requiere HTTPS con certificado válido si usás HTTPS entre CloudFront y el origen

Qué pasa cuando hay pocos cache hit (Cache Hit bajo)?
- Revisar el TTL , si es muy bajo, los objetos expiran rápido y van al origen frecuentemente.
- Revisar la Cache Key , si incluye headers, cookies o query strings innecesarios, fragmenta el caché y baja el hit rate. La solución es usar Cache Policies para controlar qué forma parte de la cache key.
Qué hacer cuando lo cacheado quedó antiguo, cómo resolver inmediatamente sin esperar que expire el TTL?
- Invalidación de caché (CreateInvalidation) hace que CloudFront descarte el objeto antes del TTL.
- Alternativa más eficiente para el examen: versionado de archivos en el nombre (app.v2.js), evita invalidaciones y es la práctica recomendada por AWS.
Behavior (comportamiento): analizar las variantes. Es útil realizar laboratorios.
- Permiten definir reglas distintas por path pattern (/api/*, /images/*, /static/*).
- Cada behavior puede tener su propio origen, TTL, política de caché y restricciones de acceso.
- Caso de uso común: /api/* apunta a ALB (dinámico, sin caché) y /* apunta a S3 (estático, con caché larga).

VPC Endpoints

Es clave conocer los tipos de punto final para aplicar seguridad a la conexión de servicios aws (sin pasar por internet).

Gateway Endpoint : Es sin costo, solo para conectar con S3, DynamoDB. Importante para sortear preguntas, solo tiene utilidad dentro de una VPC, no tiene la capacidad de acceso externo. También admite políticas de punto final para controlar el acceso.
Interface Endpoint (PrivateLink): Tiene costo. Crea una ENI con IP privada en tu VPC para conectarse a servicios de AWS (y servicios de terceros). Permite el acceso desde on-premise si existe conectividad previa (VPN/Direct Connect). Admite políticas de punto final para controlar qué entidades principales pueden usarlo.
- Al crearlo AWS genera DNS privados para el servicio, si Enable Private DNS está activado, las llamadas al endpoint público se resuelven automáticamente a la ENI privada. Resolución de problemas: si el tráfico sigue saliendo a internet a pesar de tener un Interface Endpoint → verificar que Enable Private DNS esté activado.

⬅ Apuntes para la certificación AWS CloudOps Engineer Associate (SOA-C03) - Parte 1

Apuntes para la certificación AWS CloudOps Engineer Associate (SOA-C03) - Parte 1

Laura Bolaños — Thu, 04 Jun 2026 03:00:00 +0000

Primera parte de los apuntes del examen. La idea es que identifiques los principales temas para el examen de certificación y conocer algunos tips de estudio para alcanzar con éxito tu meta 🎓

Características generales

La complejidad es de nivel medio. A mi criterio lo más complejo son las diferentes formas de soporte vía SSM.

Consta de 5 dominios y toda la información detallada la podemos encontrar aquí.

Solo se puede rendir en inglés, con lo cual es prioritario estudiar con apuntes, entrenamiento de preguntas y laboratorios en este idioma. Se aprueba con 720 puntos.

Es una certificación que te invita a conocer en profundidad las arquitecturas mas tradicionales de AWS , la resolución de problemas en producción y el mantenimiento evolutivo al momento de actualizar infraestructura para la continuidad del negocio.

⭐ Se superponen varios temas con Solutions Architect Associate y Developer Associate. Si ya rendiste alguna, te va a resultar familiar un % del contenido.

Método de estudio

Estudiar para una certificación no tiene fórmulas mágicas, se necesita apartar tiempo de nuestro dia y constancia. Tener en claro que nos permite profundizar en conceptos o prácticas que tal vez no vemos en el trabajo diario...esa será nuestras motivación.

Tu punto de partida debe ser la guia de examen siempre.
Conviene hacer la preparación de examen de SkillBuilder, te da un paneo general de temas y asi podes identificar las brechas de conocimientos en las que debes profundizar.
Mi forma favorita de estudiar es hacer una especie de RAG con NotebookLM con la documentación oficial de AWS pertinente (aws permite bajar los pdf).
La novedad es que hay mcp de AWS disponibles referidos a la documentación. Por ejemplo, utilizando los temas de la guia de examen como contexto, se puede generar apuntes. Utilice este mcp , pero tambien hay uno que no he probado que es mucho más amplio y contiene temas de arquitectura aquí

⭐ Resumen de los Dominios de examen generado por kiro con el mcp de la documentación de AWS.

⭐ Utilicé Tutorials Dojo como banco de preguntas para practicar, pero mi percepción es que las preguntas en el examen eran más difíciles.

Arquitecturas importantes

Te invito a pensar en sus variantes para lograr alta disponibilidad, escalabilidad y resiliencia. Los temas de networking son importantes en el examen: configuración de VPC, subnet, tablas de ruteo, Security Groups entre otros, especialmente troubleshooting de conectividad.

High Available (Route53)

High Available and Scalable Web App (Cloudfront - ALB)

Worker Fleet - SQS

VPC Peering

Transit Gateway

Cloudfront - OAC

Config

Temas que son claves conocer para el examen

Las preguntas de examen se centran en la resolución de problemas con menos carga operativa y la elección de arquitecturas más lógica.

CloudWatch

Familiarizarse con las features de la consola de CloudWatch porque vas a enfrentarte a varias preguntas sobre la administración de logs.

Cómo visualizó los logs comunes? **CloudWatch > Logs > Log Management. Aquí se encuentran todos los "Logs Groups" como aws/lambda/..., aws/apigateway/...,ecs/..., ec2..
Cómo creo un Log Group? Desde la CLI de AWS. Cómo inserto Log en CloudWatch? Desde la Api con Create
CloudWatch metrics, tener en claro las diferentes tipos y circunstancias a utilizar. Cada métrica tiene un nombre, namespace y dimensiones (opcional).
- Basic Monitoring (5 min, default).
- Detailed Monitoring (1 min, se habilita manualmente)
- High Resolution para métricas custom (hasta 1 segundo).
Metric Filters ➡ Definís un patrón de búsqueda sobre un Log Group y CloudWatch genera una métrica custom a partir de las coincidencias.
- El caso de uso típico a resolver: detectar cantidad de errores 500 en logs de una aplicación. Metric Filter sobre el Log Group (métrica custom) → alarma de CloudWatch sobre esa métrica y acción de remediación automática.
CloudWatch Agent ➡ es uno de las features más importantes que nos va a permitir enviar Logs a CloudWatch desde las instancias de EC2, server onprem, EKS cluster (recopilar métricas y registros a nivel de nodo de los contenedores).
- Comprender cómo se configura y se modifica el archivo de configuración del agente (sin reiniciar las instancias de EC2): amazon-cloudwatch-agent-ctl command with the fetch-config
CloudWatch Logs Insights: sintaxis y comandos para el análisis de logs ➡ fields , display , filter , stats , sort , limit ...

Escalabilidad y Elasticidad

Administración de Fleet de EC2: Estrategias para continuar procesamiento de trabajos minimizando las interrupciones de form costo-efectiva ➡ capacity-optimized para minimizar interrupciones o price-capacity-optimized para balance entre costo y disponibilidad. (Combinando instancias Spot y On-Demand con el parámetro OnDemandBaseCapacity se especifica cuántas instancias base On-Demand y el resto se cubre con Spot).
EC2 Auto Scaling Group: puede aparecer pregunta puntual sobre administrar ASG, pero por lo general no aparece como concepto aislado sino asociado a un balanceador de carga (ALB/NLB) y en arquitecturas multi-región con Route 53.
- Capacidad mínima, máxima y deseada.
- Definición de Launch template, cómo aplicar una nueva configuración a todas las instancias del ASG sin downtime? ➡ Cuando se actualiza un Launch Template, las instancias existentes no se reemplazan automáticamente, siguen ejecutando la versión anterior. Las nuevas instancias que escalen usarán la versión nueva. Para forzar el reemplazo se usa Instance Refresh.
- Distribución en AZ.
- Health Checks de EC2 o si health checks desde un ELB determina que las instancias que no están en buen estado se reemplazan automáticamente. Profundizar en este punto
- Es clave entender las siguientes políticas de escalamiento para responder sobre mejora de performance.

Tipo de Política	Cómo Funciona	Caso de Uso
Target Tracking	Mantiene una métrica en un valor objetivo (ej: CPU al 50%). AWS gestiona las alarmas de CloudWatch automáticamente.	Aplicaciones web generales donde querés simplicidad sin configuración compleja.
Step Scaling	Ajusta la capacidad en pasos según cuánto se desvía una métrica del umbral. Permite diferentes tamaños de paso según la magnitud.	Workloads con picos abruptos donde necesitás agregar más instancias cuanto mayor es el desvío.
Simple Scaling	Agrega o quita una cantidad fija de instancias cuando se dispara una alarma. Incluye período de cooldown antes de la siguiente acción.	Legacy, no recomendada. Target Tracking la reemplaza en casi todos los casos.
Scheduled Scaling	Escala la capacidad en un horario específico usando expresiones cron.	Cargas predecibles: horario comercial, cierre de mes, campañas programadas.
Predictive Scaling	Usa ML para predecir la carga futura y ajusta la capacidad de forma proactiva.	E-commerce con patrones cíclicos (ej: picos semanales o estacionales recurrentes).

LifeCycle Hooks: En Auto Scaling Group para analizar errores de las instancias antes de que se finalicen para ser reemplazadas se puede pausar la finalización de la instancia. También, este mecanismo, al inicio permite acciones como instalación de software. La instancia permanece en estado Pendiente
Conocer el término Warmup, define un tiempo de calentamiento de la instancia. Es el período posterior al lanzamiento de una nueva instancia antes de que sus métricas contribuyan a la métrica de escalado. Evita el escalado por falsas métricas hasta que la instancia se estabilice.
Application AutoScaling (no confundir con ASG):
- ECS, cantidad de task.
- Lambda. Entender la diferencia entre Provisioned Concurrency y Reserved Concurrency. La primera es la que permite "autoescalar" ➡ muy probable que te planteen una situación con Lambda para resolver temas de concurrencia.
- Aurora réplicas. Permite liberar la instancia del cluster, teniendo réplicas de lectura (no de escrituras).
- DynamoDB, puede crear una política de AutoScaling. Luego DynamoDB pública métricas de capacidad consumida CloudWatch ➡ La alarma de CloudWatch invoca a AutoScaling de aplicaciones para evaluar la política de escalado, emite una solicitud UpdateTable para ajustar el rendimiento aprovisionado de la tabla.

ELB - High availability

Con el siguiente cuadro podés responder varios casos de uso:

Load Balancer	Capa	Protocolos	Características Clave
Application Load Balancer (ALB)	Layer 7 (HTTP/HTTPS)	HTTP, HTTPS, gRPC, WebSocket	Enrutamiento basado en contenido (path, host, headers, query strings), targets Lambda, integración con WAF, sticky sessions.
Network Load Balancer (NLB)	Layer 4 (TCP/UDP)	TCP, UDP, TLS	Ultra-baja latencia, IP estática por AZ, soporte Elastic IP, preserva la IP de origen, maneja millones de requests/segundo.
Gateway Load Balancer (GWLB)	Layer 3 (IP)	IP	Despliega, escala y gestiona appliances virtuales de terceros (firewalls, IDS/IPS). Usa protocolo GENEVE.
Classic Load Balancer (CLB)	Layer 4 y 7	HTTP, HTTPS, TCP, SSL	Legacy; no recomendado para nuevos despliegues.

Dónde encontrar información detallada como la dirección IP del cliente, latencias, rutas de solicitud y respuestas del servidor? ➡ La respuesta es habilitar los ELB Access Logs y almacenarlos en un bucket de S3.
Problemas de conectividad. Una web inalcanzable con grupos de seguridad correctos ➡ La solución es permitir puertos efímeros (1024-65535) en la Network ACL (NACL), porque ELB utiliza este rango para comunicarse con los clientes.
Sticky Sessions: Caso de uso donde una sola instancia EC2 tiene un uso de CPU del 95% mientras las otras están al 10% ➡ ajustar la expiración de las cookies de la aplicación para rebalancear la carga.
Conocer Cross-Zone Load Balancing para asegurar una distribución uniforme del tráfico en todas las zonas de disponibilidad habilitadas.
Integración de ALB con WAF pero no así con NLB.

Placement Group

Cluster: Agrupa las instancias muy cerca unas de otras en una única zona de disponibilidad. Proporciona una red de baja latencia y alto ancho de banda (hasta 100 Gbps con EFA). Casos de uso ➡ HPC, Machine Learning,

Partition: Divide las instancias en particiones lógicas, cada una en racks separados con alimentación y red independientes. Hasta 7 particiones por zona de disponibilidad. Caso de uso ➡ base de datos Distribuidas: Cassandra,HDFS, Kafka

Spread: Cada instancia se ubica en un hardware distinto (racks separados). Máximo 7 instancias por zona de disponibilidad por grupo. Caso de Uso ➡ grupos de instancias que deben aislarse entre sí en hardware separado.

Estrategias de Disaster Recovery

Conceptos principales RTO (Recovery Time Objective), RPO (Recovery Point Objective) ➡ mientras mas pequeños mas costosos. Este enlace tiene información detallada que vale la pena revisar de las siguientes estrategias:

Estrategia	RTO	RPO	Costo	Caso de Uso
Backup and Restore	Horas	Horas	$	Dev/test, no-crítico
Pilot Light	Varios minutos	Minutos	$$	Apps internas, criticidad moderada
Warm Standby	Minutos	Segundos–minutos	$$$	Apps de negocio críticas
Multi-Site Active/Active	Segundos	Segundos	$$$$	Crítico, zero-downtime

Clases de S3 - Versiones - Eventos

Hacer un pequeño cuadro comparativo de versiones de S3 y que casos de uso se utiliza para cada uno. Ejemplo ➡ cuando los patrones de acceso son impredecibles o cambiantes y no querés gestionar manualmente las políticas de ciclo de vida: S3 Intelligent-Tiering
S3 Object Lock ➡ cuando se usa Governance mode o Compliance mode.
Activación de versionado. Relación con CRR (Cross Region Replication) y SRR (replicación en misma región pero diferentes cuentas).
- Resolución de problemas de latencia o errores cuando el S3 es origen de CloudFront: Si hay millones de versiones y las operaciones de listado o ciclo de vida se vuelven pesadas ➡ Configurar S3 Lifecycle Policies para expirar versiones antiguas automáticamente, usando NoncurrentVersionExpiration para eliminar versiones no actuales después de cierta cantidad de días.
Event notifications para creación, eliminación, update de objetos. Integración con Lambda, SNS y Eventbridge. EventBridge permite filtrar eventos por prefijo, sufijo, tamaño, etc. y enrutarlos a más de 20 destinos distintos.
Conocer las políticas de bucket para responder preguntas sobre que habilita o deniega una policy. Su alcance. Entender que un Deny explícito siempre gana, incluso si hay un Allow en otra política.

ElastiCache

Conocer las llamadas básicas de la API es básico ➡ saber como crear un cluster CreateCacheCluster, parámetros importantes como CacheNodeType

ElastiCache - Memcached: caso de uso que recibe alertas relacionadas con un alto uso de CPU en un clúster de Amazon ElastiCache Memcached, cómo solucionarlo? ➡ Agregar nodos adicionales proporcionará mayor capacidad al clúster o bien según la versión de Memcached se puede escalar verticalmente cambiando el tipo de nodo sin necesidad de crear un nuevo cluster. No tiene replicación, ni persistencia.
ElastiCache - Redis: El concepto más importante de esta opción es permitir Alta Disponibilidad a través de sus réplicas: Multi-AZ con failover automático. División en sharding. Compatible con PUB/SUB. Adecuado para conservar sesiones. El soporte más común a resolver por performance es cambiar el tipo de nodo.

SSM (Simple Service Manager)

Si no trabajas todos los días con este servicio, es necesario que no solo estudies teoría en cuanto a sus features, sino que también hagas laboratorios.

Las preguntas que aparecen en el examen son muy variadas en cuanto a la administración de EC2, aplicación de parches, auto aprobaciones de releases y algunas que involucran webhooks con github.

Recomiendo mirar la sintaxis de los documentos en JSON o Yaml que definen acciones y flujos de trabajo automatizados ➡ hay preguntas sencillas sobre este punto en el examen.

Enumero algunas situaciones o casos de uso:

Un concepto sencillo útil: todas las ejecuciones se puede trackear su estatus y log de salidas desde la consola de System Manager.
Se quiere automatizar la creación de Amazon Machine Images (AMIs) personalizadas. Se detecta errores timeout sobre el pipeline de EC2 Image Builder ➡ El agente de AWS Systems Manager (agente SSM) en la instancia de compilación no se está ejecutando o no está accesible.
¿Cómo dividimos los parches entre servidores de diferentes cuentas/entornos y SO? ➡ La solución combina Patch Baselines (definen qué parches aplicar, con aprobaciones automáticas y listas de rechazo, por SO) + Patch Groups (agrupan nodos mediante tags y los asocian a una Baseline específica).

Runbook: Tipo específico de documento de Systems Manager (SSM) que define las acciones exactas que realiza el servicio Automation. Define yaml o json para orquestar un workflow de ejecución.

Por lo general, se usa para la remediación asociado con AWS Config.
Usando AWS Organizations se necesita automatizar el proceso de stopping de instancias EC2 no productivas fuera del horario de negocio de todos las cuentas miembro ➡ Crear roles de IAM en cada cuenta con los permisos adecuados, utilizar Systems Manager Automation con una cuenta de administrador delegado para ejecutar un runbook que dirija los recursos de toda la organización según los tags.
Patch Policies: se utiliza para Organizations. Tener en claro que centraliza el control para definir patching schedules y baselines para múltiples cuentas y regiones
Revisar los documentos de ejecuciones más importantes en SSM.
Integraciones por eventos externos, tener claro cómo trabaja en los diferentes casos webhooks (con avisos de software de terceros). Que flujos podemos tener:
- Webhook → API GW → Lambda → SSM
- GitHub Actions → SSM (puedes filtrar exactamente por eventos RELEASED o PRERELEASED).
- Amazon EventBridge Partner Events → GitHub como fuente nativa de eventos → SSM Automation o Lambda como destino.
- EventBridge Scheduler → Lambda consulta GitHub API → escribe versión en SSM Parameter Store (como fuente de verdad para actualizaciones)
AWS RunRemoteScript: Documento SSM que permite ejecutar scripts alojados en S3 o GitHub directamente en los nodos, sin necesidad de copiarlos previamente.

Servicios y estrategias de Deployment

Casos de uso de AWS Code Pipeline, y los otros servicios que involucra ➡ Code Commit o GitHUb, Code Build, Code Deploy o CloudFormation. Entender donde se integran los test y tener en cuenta que se puede agregar una aprobación vía sns antes de realizar deploy.
CodePipeline puede implementar CloudFormation StackSets, lo que permite implementaciones en múltiples cuentas y regiones como parte de una canalización de CI/CD.
Estrategias de deployment:
- In-place (All-at-once): Implementa en todas las instancias simultáneamente. Downtime Posible. Es Lento (redeploy versión antigua). Se usa en entornos de desarrollo, cuando el downtime es aceptable
- Rolling: Reemplazar instancias en lotes. Downtime Mínimo. Se usa cuando querés ahorrar costos sin aprovisionar nueva infraestructura.
- Rolling with additional batch: Agrega nuevas instancias antes de eliminar las antiguas. Downtime mejor que el anterior. Se usa cuando necesitas mantener capacidad completa durante el deploy
- Immutable: Inicia instancias completamente nuevas; intercambia cuando estén en buen estado. Se usa en producción donde el rollback rápido es crítico.
- Blue/Green: Ejecuta dos entornos idénticos; cambia el tráfico. Downtime mínimo. Se usa cuando necesitás rollback instantáneo y podés asumir el costo de doble infraestructura.
- Canary: Desvía primero un pequeño % del tráfico; lo va ampliando si todo está OK. Es rápido. Se usa para validar un release con un subconjunto de usuarios antes de rollout completo.

Cloudformation

Es un servicio fundamental en el examen. Conocer las secciones principales de la plantilla (JSON o YAmL) : Metadata, Parameters, Mappings (caso de uso de parametrización de Amazon Machine Images (AMIs) ), Conditions, Transform (SAM), Resources.

Una buena práctica para familiarizarse con la sintaxis de los templates es construir arquitecturas clásicas que utilicen EC2, ASG, ALB, RDS con Secret Manager, entre otras.
Comandos CLI importantes:
- aws cloudformation create-stack ➡ crea un stack nuevo
- aws cloudformation deploy ➡ crea o actualiza un stack usando un template empaquetado (más usado en CI/CD)
- aws cloudformation detect-drift ➡ inicia la detección de drift en un stack
- aws cloudformation describe-stack-drift-detection-status ➡ consulta el resultado de la detección
- aws cloudformation cancel-update-stack ➡ cancela una actualización en curso
StackSet ➡ caso de uso importante de cuentas asociadas en Organizations. Gestiona de manera centralizada para implementar cambios en las stack en varias cuentas. Se puede usar StackSets para crear, actualizar o eliminar stacks en varias cuentas y regiones de AWS con una sola operación.
Intrinsic functions: comandos que se utilizan dentro de las plantillas para asignar valores a propiedades que no están disponibles hasta el momento de la implementación (en tiempo de ejecución) ➡ revisar implementaciones de las mas importantes: Ref , Fn::GetAtt, Fn::ImportValue, Fn::FindInMap, Fn::ForEach, Fn::Transform ...
NestedStack: AWS::CloudFormation::Stack ➡ mecanismo para crear infraestructura modular, reutilizable y gestionable mediante la integración de una pila dentro de otra. En lugar de crear una plantilla única y masiva que resulta difícil de mantener, se puede dividir la arquitectura en componentes lógicos (por ejemplo, VPC, base de datos, capa de aplicación) y referenciarlos como pilas separadas dentro de una plantilla "raíz" o "padre".
Mecanismos de protección en CloudFormation:
- Stack Policy: documento JSON que restringe qué recursos pueden ser actualizados. Ideal para proteger RDS de producción de cambios accidentales.
- Termination Protection: protección a nivel stack contra eliminación accidental. Se hereda a los nested stacks.
- DeletionPolicy: Retain conserva el recurso, Snapshot genera snapshot antes de eliminar (soportado en RDS, EBS). La situación típica que se plantea, como conservar una RDS si se elimina el stack de cloudformation?
- UpdateReplacePolicy: igual que DeletionPolicy pero aplica cuando un update requiere reemplazar el recurso físico.
- Drift Detection: detecta recursos cuya configuración real difiere del template, útil para identificar cambios manuales que bypasearon el pipeline.
Profundizar en los Script Auxiliares más importantes, mecanismos para sincronizar la creación o actualización de recursos, para que el stack espere hasta que la configuración esté lista antes de continuar.
- cfn-init → lee y ejecuta la sección AWS::CloudFormation::Init del template (instala paquetes, archivos, servicios). Se ejecuta durante el User Data.
- cfn-signal ➡ Generalmente se implementa al final de un script de User Data. Un patrón común es ejecutarlo después de cfn-init
- Tener en cuenta los atributos que requieren señales como CreationPolicy (puede estar asociados con AWS::EC2::Instance o AWS::AutoScaling::AutoScalingGroup ) y los tipos de UpdatePolicy (con WaitOnResourceSignals).
CloudFormation Traffic Shifting ➡ se implementa definiendo DeploymentPreference en el template. CodeDeploy ejecuta el shifting según la estrategia elegida (Canary, Linear, AllAtOnce).

Storage

Evaluar y seleccionar que tipo de Storage es adecuado a un caso de uso. Si estudiaste para la certificación de SAA son preguntas similares.

Storage en entornos híbridos ➡ Storage Gateway y todas sus variantes
- S3 File Gateway: Acceso NFS/SMB a objetos en S3. Los archivos se almacenan como objetos nativos. Caso de uso: migración de archivos on-premise a S3.
- Volume Gateway:
- Cached mode: datos principales en S3, caché local de los más accedidos.
- Stored mode: datos principales on-premise, backup asíncrono a S3 como EBS snapshots.
- Tape Gateway: Reemplaza cintas físicas. Importante es que se expande automáticamente, esta última característica puede ser un caso de uso que aparezca en el examen.
- FSx File Gateway: Caché local de FSx for Windows File Server para acceso de baja latencia desde on-premise.
FSx for Windows FileServer y su otras variantes, cuando usarlo?
- Es MultiAZ, es una feature importante.
- Shadow Copies: los usuarios finales puedan ver y restaurar por sí mismos versiones anteriores de archivos o carpetas individuales sin depender de otro mecanismo.
- Usado con Windows SMB, Active Directory.
FSx for Lustre ➡ HPC, ML, high throughput
EFS (Elastic File System) comprender el caso de uso que puede compartir storage entre varias EC2, Linux NFS.
- Multi-AZ
- Performance modes: general Purpose y MaxIO
- Throughput Modes: Elastic (recomendado), Provisioned, Bursting.
- Conocer qué EFS tiene Storage Class y Lifecycle Policies ➡ aunque suele no aparecer en el examen.
EBS ➡ siempre en el contexto de EC2 y la elección del disco para optimizar las cargas de trabajo: gp3 sobre gp2 sin incrementar los costos, gp3 permite configurar IOPS y throughput independientemente del tamaño del volumen. Para transacciones, persistencia y durabilidad es io2
- Amazon Data Lifecycle Manager (DLM): Automatiza la creación, retención y eliminación de instantáneas de EBS y AMI respaldadas por EBS mediante políticas de ciclo de vida.
- EBS Snapshot: Una copia de seguridad puntual de un volumen EBS almacenado en S3 (gestionado por AWS). Los snapshot son incrementales.

RDS y Aurora

Los accesos se deben guardar en Secrets Manager y luego las aplicaciones acceden a eso. Característica importante Cross-Region backup replication. Tanto RDS como Aurora tienen PITR (Point-in-Time Restore).

RDS Multi-AZ ➡ standby síncrono en otra AZ, failover automático pero más lento que Aurora.
Se puede asociar con el servicio RDS Proxy para el manejo de conexiones.
Aurora ➡ Almacenamiento distribuido que se replica automáticamente en 3 AZs, hasta 15 réplicas de lectura, failover automático en segundos.
Aurora Serverless v2 ➡ la característica importante es que escala a "cero" y no genera costo.

DynamoDB

Las preguntas se centran en resolver problemas de performance; cómo volver a un recovery point. Ejemplo: La tabla experimenta picos de tráfico incrementales durante el horario laboral, con patrones predecibles, cuando se producen millones de lecturas y escrituras. Hay que configurar una solución para aumentar la capacidad de procesamiento ➡ Habilitar el escalado automático en la tabla de DynamoDB. Configurar una política de escalado automático para ajustar el tamaño en función de las unidades de capacidad de lectura y escritura.

Point-in-Time Recovery (PITR) ➡ backup continuo, permite restaurar a cualquier segundo de los últimos 35 días.
Para esto debemos conocer los tipos de Lectura Eventually Consistent Read (por defecto) y Strongly Consistent Read
Los diferentes modos de capacidad On-Demand y Provisioned (profundizar en estos dos conceptos).
DynamoDB Global Tables ➡ replicación multirregional y multiactiva. Cada región puede aceptar lecturas y escrituras, y los cambios se replican de forma asíncrona. Esto permite la escalabilidad global y la recuperación ante desastres.

Encriptación en reposo, tránsito y uso de KMS

Encriptación con S3 de KMS: SSE-S3 (clave gestionada por AWS), SSE-KMS (usás una KMS key propia, permite auditoría via CloudTrail y control de acceso granular) y SSE-C (el cliente provee la clave, AWS no la almacena). Si la pregunta menciona auditoría de uso de claves o control granular ➡ SSE-KMS.
Clave simetrica y asimetrica son básicos. Aunque en el examen no hay preguntas profundas sobre este punto.
Key Policies: Cada clave KMS tiene una política de claves. Una política basada en recursos que controla quién puede usar y administrar la clave. A diferencia de las políticas de IAM, la política de claves es el principal mecanismo de control de acceso para las claves KMS.
Rotación de Key, hay 3 variantes:
- automática, para customer managed keys puede habilitar la rotación automática
- manual u On-demand por medio de trigger.
Importación de material de clave de un cliente en KMS, pero no rota automáticamente.
Replicación AWS KMS Multi-Region Keys: Una clave KMS que existe en una región diferente, pero comparte el mismo ID de clave y material de clave que su clave principal.

AWS Certificate Manager (ACM)

Las preguntas son sencillas, si se habla que servicio proporciona certificados SSL/TLS la respuesta es ACM.

Revisar los casos de uso de como integrar ACM con ELB, CloudFront, ApiGateway, Elastic Beanstalk, Cognito.
Tipos de certificados ➡ públicos, privados e importación de terceros. Identificar los casos de uso para poder resolver situaciones.
Mecanismo de renovación e importación de certificados de terceros.

Seguridad IAM

Pensar que todo servicio para ejecutar algo debe tener un rol de IAM asociado. En ciertas ocasiones para permitir que usuarios utilicen servicios o listen ciertas features de manera temporal podemos agregar inline policies y luego eliminarlas.
Casos de uso de iam:PassRole. Entender por qué es una capa de seguridad importante para proteger el entorno de AWS de actividades no deseadas y de la escalada de privilegios.
Caso de uso de credenciales temporalesiam:AssumeRole. Ejemplo ➡ la entidad en la Cuenta A utiliza para ejecutar servicios en la Cuenta B como si fuera un usuario local en esa cuenta.
Federación de Identidades: Permite a los usuarios autenticados por un proveedor de identidad externo (IdP) acceder a AWS sin crear usuarios de IAM individuales. Conocer los casos de uso:
- SAML 2.0: se integra con Microsoft Active Directory Federation Services (ADFS) u Okta. Los usuarios se autentican con sus credenciales corporativas y reciben credenciales temporales de AWS.

OpenID Connect (OIDC):

para aplicaciones web y móviles. Admite proveedores de identidad como Google, Facebook o cualquier proveedor compatible con OIDC. Solución de error "Not authorized to perform sts:AssumeRoleWithWebIdentity" ➡ agregar el ARN del proveedor de identidad en el elemento principal de la política de confianza (trust policy).

AWS Organizations

OU (Organizational Units): las cuentas se agrupan en OUs y los SCPs se aplican a nivel OU o cuenta individual, heredando hacia abajo en la jerarquía.
Delegated Administrator: permite que una cuenta miembro (no la cuenta de administración) gestione servicios específicos como Security Hub, GuardDuty o Config para toda la organización.
Relaciona el concepto de administrar muchas cuentas con Service control policies (SCPs). Recordar que afectan únicamente a los usuarios y roles de IAM gestionados por las cuentas que forman parte de la organización. SCPs no afectan directamente a las políticas basadas en recursos.
Políticas de tagging. Se puede asegurar que los usuarios no puedan crear recursos sin una etiqueta específica.
Integración con CloudFormation StackSet. Definir un StackSet que implementa una plantilla base (almacenada en S3) en toda una Unidad Organizativa (OU) en varias regiones utilizando Service-Managed permission model.
Consolidated Billing: todas las cuentas miembro consolidan el pago en la cuenta de administración, permite aprovechar descuentos por volumen y Reserved Instances compartidas entre cuentas.

AWS Artifact

Su caso de uso es acceder a informes de auditoría. Se puede descargar bajo demanda certificaciones de cumplimiento normativo (como SOC 1/2/3, ISO/IEC, y PCI DSS).

Este apunte continua en ➡ Apuntes para la certificación AWS CloudOps Engineer Associate (SOA-C03) - Parte 2

Patrones de acceso seguro a S3 🌐

Laura Bolaños — Mon, 27 Apr 2026 14:09:23 +0000

Este análisis se propone clarificar algunos casos de uso donde se requiere servir contenido de S3 de manera segura, identificando las brechas de seguridad a las que debemos enfrentarnos y explorar posibles mejoras. El desafío real no está en analizar cada servicio por separado, sino en combinarlos correctamente.

1. CloudFront + OAC con presigned url

Caso de uso frecuente: Un sitio web que muestra imágenes/vídeos de una temática determinada. Una parte de los objetos multimedia puede restringirse a que solo lo vean usuarios que iniciaron sesión vía Cognito. Aquí la solución más sencilla:

Upload de Multimedia (escritura)
El frontend solicita una Presigned URL a un endpoint protegido por Cognito (una api). La api se integra con una función Lambda que genera una URL temporal (válida por x minutos) firmada con permisos de "s3:PutObject" para el bucket privado de imágenes.

Visualización de Multimedia (lectura)
El bucket de S3 tiene el bloqueo de acceso público activado.
Los elementos multimedia se sirven a través de CloudFront, utilizando OAC (Origin Access Control) para firmar internamente la petición (usando el protocolo SigV4) y solicitar el objeto a S3 de forma segura.
La política (Bucket Policy) del bucket S3 solo permite la acción "s3:GetObject" si la petición proviene específicamente del ARN de la distribución de CloudFront ("Condition: AWS:SourceArn").

Conceptualmente una Presigned URL se puede utilizar tanto para cargar como para leer objetos, en el ejemplo anterior notar que solo se usa para cargar los objetos a S3*.* Una presigned URL es simplemente una URL con la firma embebida ➡ cualquiera que la tenga puede usarla hasta que expire, sin autenticación. Por eso debemos aplicar diferentes técnicas de seguridad.

La url puede tener una duración desde 1 minuto hasta 12 horas, si alguien no autorizado consigue la url y ya caduco ➡ NO la puede utilizar.
Con el uso de Cognito, el token JWT tiene una duración y se puede aplicar este control con Cognito JWT Authorizer (nativo de API Gateway). La otra posibilidad es tener Lambda Authorizer en API Gateway. Esta última tiene lógica de autorización custom.
Cuando generamos una presigned url para upload, se puede controlar que tipos de objetos cargar y su peso máximo. Algunos ejemplos:

# Generate presigned URL for PUT
# ContentType specifies the types of objects and controls their size on the frontend
upload_url = s3_client.generate_presigned_url(
            "put_object",
            Params={
                "Bucket":      IMAGES_BUCKET,
                "Key":         imagen_key,
                "ContentType": expected_content_type,
            },
            ExpiresIn=PRESIGNED_URL_TTL,
)

# the frontend makes a multipart POST request
response = s3_client.generate_presigned_post(
    Bucket=IMAGES_BUCKET,
    Key=imagen_key,
    Fields={
        "Content-Type": expected_content_type,
    },
    Conditions=[
        {"Content-Type": expected_content_type},
        ["content-length-range", 1, 5242880],  # máx 5MB
    ],
    ExpiresIn=PRESIGNED_URL_TTL,
)

1.2 Caso de uso complementario - Validación de acceso en el edge (Lambda@Edge)

Podemos enfrentarnos a dos requerimientos no funcionales: minimizar la latencia y asegurar quién puede hacer request a Cloudfront.
El caso anterior asegura que solo CloudFront puede acceder a S3, pero no controla quién puede hacer requests a CloudFront. Con Lambda@Edge es posible agregar lógica de autorización en los nodos de la CDN, antes de que el request llegue al origen. La secuencia es la siguiente:

Cuando un usuario solicita un objeto de un bucket, CloudFront invoca una función Lambda@Edge en el nodo más cercano geográficamente.
La función valida el JWT de Cognito (o cualquier token de sesión) sin necesidad de redirigir el request al backend.
Si el token es válido, el request continúa hacia S3 a través de OAC normalmente.
Si no es válido, Lambda@Edge retorna un 401 o redirige al login desde el edge.

⭐ La ventaja es la baja latencia, la validación ocurre en el edge node más cercano al usuario, sin necesidad de viajar hasta la región de AWS donde vive el backend. Cada request de contenido protegido se resuelve en milisegundos en lugar de sumar el tiempo de ida y vuelta a tu servidor.

2. Descarga temporal de un archivo privado - S3 Presigned URLs

Para esta opción el casos de uso típico: Un usuario necesita descargar un reporte generado, una factura o un documento legal guardado en bucket S3. No se utiliza Cloudfront porque no necesitamos cachear contenido de la petición.

Se produce la petición del usuario, el backend valida que ese usuario tiene permiso sobre ese archivo específico.
Lambda genera una presigned URL con GetObject que expire entre 5-15 min. La lógica de validación de lambda es idéntica del caso de uso 1 de Upload.
El browser descarga directamente desde S3 usando esa URL.

🔐 Brechas de seguridad detectadas

Riesgos de seguridad	Mitigación posible
El usuario la copia y la comparte intencionalmente o no.	TTL muy corto (1-2 minutos si es descarga inmediata)
Queda en logs del browser, proxies o herramientas de red	Generar la URL y redirigir directamente (`302`) en lugar de devolverla al frontend (nunca queda expuesta en el browser)
Se filtra por un `Referer` header en un redirect	Incluir el `userId` en la key del objeto (`uploads/{userId}/{filename}`) para que aunque alguien obtenga la URL, solo pueda acceder al archivo de ese usuario específico.

3. Distribución segura con cookies por sesión - CloudFront Signed Cookies

Caso de uso típico: Una plataforma web con contenido que se accede por suscripción, los usuarios se loguean pero cada sesión debe tener acceso acotado en el tiempo. En lugar de firmar URL por URL, el backend emite una Signed Cookie de CloudFront al momento del login, que el browser envía automáticamente en cada request de objetos multimedia.

El backend verifica la sesión y envía tres headers Set-Cookie al browser (CloudFront requiere exactamente tres pares clave-valor para una Signed Cookie). Estos headers deben enviarse antes de que el usuario solicite el contenido privado.
Si se configura un tiempo de expiración corto, el backend puede reenviar tres nuevos headers Set-Cookie en requests posteriores para mantener el acceso activo.
CloudFront valida las cookies en cada request antes de servir los objetos multimedia. La distribución debe tener al menos dos comportamientos de cache: uno público y uno que requiere autenticación. La sección privada redirige al login si no hay cookie válida.
Al cerrar sesión o expirar las cookies, el acceso se revoca sin cambiar las URLs.

⭐ Esta opción es Ideal cuando un usuario accede a múltiples objetos multimedia de una misma sección sin generar una firma por cada archivo.
⭐ Si CloudFront se configura para cachear basándose en cookies, NO generará entradas de caché separadas por los atributos de las Signed Cookies. Es decir, todos los usuarios autorizados compartirán la misma entrada de caché para un objeto determinado— CloudFront valida la cookie para permitir o denegar el acceso, pero la ignora al construir la cache key.

Aspectos generales a tener en cuenta

➡ Diseño
Considerar Patrón BFF (Backend for Frontend). Para el caso de descarga privada, se puede interponer una capa BFF entre el frontend y API Gateway. Esta capa maneja la sesión del usuario y puede ejecutar un redirect 302 directo hacia S3, evitando que la presigned URL quede expuesta en el browser.

➡ Performance/Costo
Invalidaciones de CloudFront (incurre costo después de 1000/mes). Además del costo analizar tiempo de cacheo de datos.

S3 request rates (3500 PUT/5500 GET por segundo por prefix, si el volumen es alto distribuir con prefijos).

Costo de Lambda por invocación para generar presigned URLs a escala.

➡ Seguridad
Rotación de claves KMS si el bucket usa SSE-KMS.

Versionado de objetos en S3 para evitar sobreescritura accidental.

➡ Operacional
TTL de presigned URLs vs tiempo de expiración del JWT — si el JWT expira antes que la URL, tenemos un problema!

Estrategia de nombres de objetos (userId/filename) para evitar colisiones y facilitar políticas IAM por prefijo.

Pensar en Serverless para crear bellos sueños 🦋

Laura Bolaños — Fri, 10 Apr 2026 12:56:18 +0000

En estas líneas te explico una sencilla arquitectura para desplegar un sitio web íntegramente utilizando servicios Serverless que podría servir, como en mi caso, para mostrarle al mundo mi interés por la ecología (con repositorio github incluido)

En un mundo digital donde se crean productos financieros, web que muestran dashboard de eficiencias, p&L y todo tipo de temáticas asociada al dinero ...y que está muy bien! olvidamos que nuestro hábitat natural necesita ayuda.
Hace unos años me percate de esto y comencé a leer/hablar de árboles, arbustos y plantas mal llamadas malezas - nativas de mi región que son fuente de alimento de mariposas e insectos que son fundamentales para la biodiversidad - que están desapareciendo con el avance de las especies exóticas, los agroquímicos y la destrucción de humedales.
La mayoría de las personas cuando comentas la problemática te dice "OK estoy de acuerdo contigo" pero no activan en tener un pequeño jardín de nativas o a la hora de elegir un árbol para su vereda priorizan especies exóticas solo por estetica, sin saber que muchas nativas son igual de hermosas y además sostienen la fauna local (hablo especialmente de la Provincia de Buenos Aires, Argentina).

....Y qué pasaría si cambio mi discurso en mi afán de convencer y digo: "si no ayudamos plantando nativas en nuestros hogares las mariposas pueden desaparecer" ¿Suena drástico? pero en gran parte es cierto. Estudios afirman que la población ha disminuido muy rápido, especialmente la mariposa Bandera Argentina debido a que no encuentra su planta nutricia (Coronillo) donde desovar sus huevos 💔 Cabe aclarar que la disminución de mariposas afecta directamente a la polinización y con esto atenta contra la seguridad alimentaria.
Por todo lo anterior y para bajar un poco el dramatismo decidí hacer algo: crear un proyecto web que muestre mariposas e indique la planta nativa nutricia que alimenta sus orugas! Y que los usuarios registrados puedan cargar avistamientos de mariposas en la región. Para acompañar esta idea pensé en una arquitectura Serverless, que reduce la huella de carbono y acompaña mi pensamiento ecológico 🌱.

Comencemos analizando la arquitectura

Como podés observar el laboratorio es de un nivel entre 100 y 200 (si necesitas ayuda me comentas).
Implementa una arquitectura Serverless de 3 capas:

Web Tier:
S3-Sitio Web + CloudFront ➡ contiene todo el sitio web creado con react. El código está preparado para integrar con los servicios Apigateway y Cognito. Cloudfront servicio para servir el sitio web de S3. Este s3 no es público, solo se accede a través de Cloudfront.

App Tier:
Cognito + API Gateway + Lambda ➡ Cognito realiza la autenticación del usuario que se inicia sesión. Se aclara que los usuarios se deben crear manualmente por la Consola de AWS o por cli (explicado en el Readme de repositorio). Las Lambdas de crear imagen, get imagen, presigned_URL y delete imagen(funcionalidad no desarrollada aún desde el frontend) se invocan via Apigateway. Solo los usuarios autorizados por Cognito pueden acceder a estas funcionalidades.
Las lambdas están codificadas en Python.

Data Tier:
DynamoDB + S3 - imágenes ➡ Toda la información de la fichas de las imágenes de mariposas se guarda en DynamoDB incluyendo la presigned-URL de S3-imagenes. En este último bucket se guardarán las imágenes de mariposas subidas por el usuario.
Aunque Route53 aparece en el diagrama, en el repo no lo vas a ver codificado en la IaC. Por qué? porque para el entorno educativo del laboratorio no es necesario, con la url de cloudfront el sitio web queda totalmente funcional.

⭐ El objetivo es construir una aplicación real con autenticación, subida de archivos y CRUD completo utilizando solo servicios serverless de AWS, con la opción de deployar en CloudFormation o Terraform. Porque también es muy importante aprender las diferentes formas de desplegar sin tocar el Console Home.

Como utilizar el repositorio de código

✅ Ten en cuenta que como requisito para comenzar con este ejercicio necesitas instalado Python, Terraform, AWS Cli (todo explicadisimo en el repo 🤓)

El código se encuentra en una url de un repositorio padre labs-aws-llb donde hay otros laboratorios, pero el que nos interesa es: webAppServerles.

Comenzar leyendo Arquitectura.md que explica un poco la secuencia de las acciones en los componentes y las decisiones de Arquitectura, como por ejemplo por qué no pasar las imagenes por el payload de Lambda.
Leer el Readme.md principal: contiene el paso a paso que debes hacer y si decides hacer el deploy con terraform o cloudformation te indicará ir a su correspondiente directorio. Cada directorio también contiene su Readme.md.
Leer Integration.md : te vas a encontrar que una vez deployada la IaC en AWS, solo necesitarás tomar los outputs de terraform o el descripción del stack de cloudformation y configurar el archivo aws-config.ts . Luego volverás al Readme principal para seguir el paso a paso ➡ volver a subir la web buildeada a S3 y crear una invalidación de CloudFront para actualizar la web integrada con el backend.
El laboratorio tiene un costo mínimo (si estás en la capa gratuita cero) Como siempre recomiendo limpiar todo lo desplegado. Si estas pensando en crear una web funcional estable ten en cuenta los costos. Información detallada en Readme principal.

Funcionalidades

Una vez deployado el sitio web siguiendo las indicaciones, tenemos las siguientes funcionalidades.

Feature	Usuario anónimo	Usuario logueado
Ver catálogo de mariposas precargadas	🦋	🦋
Ver galería de avistamientos de usuarios	❌	🦋
Subir foto + metadata de avistamiento	❌	🦋
Filtrar por ecorregión	🦋	🦋
Ver ficha detallada de mariposa	🦋	🦋

Después de todo el trabajo... con la url de Cloudfront descubrirás esta hermosa web funcional de mariposas bonaerenses 💗 sustentada íntegramente con servicios serverless.

En el título hablo de sueños porque realmente lo es, sueño que mis vecinos tengan aunque sea solo un ejemplar nativo. No hay estadística clara sobre la vegetación nativa, pero sabemos que las especies van retrocediendo y con esto también las mariposas.
La foto principal es una Monarca del Sur recién nacida en mi jardín, ya que generé las condiciones para que eso pasara.
Este laboratorio sirve para mostrar que casi sin costo podemos difundir información sobre temas que nos favorecen a todos y a todas. Y en tu región, ¿qué mariposas habitan?

DEV Community: Laura Bolaños

Una novedad en Serverless bajo la lupa: AWS Lambda Web Functions

Introducción

Qué es una Lambda Web Function

Lo que cambia de verdad

Dónde NO lo usaría

¿Reemplaza a API Gateway / function URLs?

Casos de Uso del playground

Un agente strands harness con streaming

Un BFF con microservicios (pedidos + inventario)

Experimento 1 ➡ Carga: ¿cuánta CPU se cobra?

Experimento 2 ➡ ¿Cuánto cuesta un pedido?

Conclusiones

Las ventajas que comprobé en el playground

Sobre migrar

Medir antes de decidir

Lecciones aprendidas

Referencias

Sumergiéndonos en Strands Agents Harness 🐬

Introducción

Conceptos clave de Strands harness

Tres formas de comenzar a crear tu Agente.

Configurar el harness mediante la CLI

Configurar el harness mediante tu agente de Código (kiro, claudecode, codex...)

Usalo como una librería (library)

Qué trae el agente por defecto

Cómo se ejecuta un agente: el agent-loop y los turnos

Sesiones, memoria y contexto: lo que el agente arrastra entre turnos

La interfaz create_harness(...) y cómo podemos acceder

Observar logs del modelo y Evaluar el agente (evals)

Primeras pruebas: lo que la documentación no te cuenta

Nova-2-lite (Amazon Bedrock)

Gemini (Google)

Algunas soluciones que podés adoptar

Inconvenientes con Unicode en consola (Windows)

Sesiones: mantener una conversación entre ejecuciones

Un caso de uso completo: Narrador de Historias

La arquitectura: un orquestador y tres subagentes

Subagentes trabajando para un orquestador

Ojo con el modelo: Agent crudo necesita una instancia de modelo

La biblia con structured output

Human-in-the-loop: un capítulo por turno

Dos modelos, un mismo harness: cada uno con su personalidad

Qué queda por explorar

Conclusiones

Referencias

Camino a AWS Certified Developer — Associate (DVA-C03): qué cambia y por qué

Por qué actualizan el examen

Datos generales de la nueva versión de examen

Lo estructural: los 4 dominios se mantienen

Incorporación 1: una Task completa de seguridad de AI (Task 2.3)

Incorporación 2: AI-assisted development transversal a los 4 dominios

Incorporación 3: Gestión de contenedores

Incorporación 4: Nuevos servicios que entran en el alcance del examen

Lo que se consolida (menos memorizar features aislados, más criterio)

Cómo armaría el plan de estudio hoy hasta esperar el detalle de la nueva guía de examen

Fuentes

A2A en Strands: agentes remotos con routing determinístico y discovery dinámico

Introducción

Conceptos Clave

➡ Protocolo A2A en Strands

➡ A2AAgent dentro de otros patrones de orquestación en Strands

➡ Creando un A2A Server

➡ Strands A2A Tool: descubrimiento dinámico

➡ Evaluaciones (Evals)

Descripción de la solución

Ejecución Local

Conclusiones

Recursos

Workflow en Strands: un DAG de tareas ejecutado como herramienta única

Introducción

Conceptos Claves

➡ Workflow de Agentes es un patrón de orquestación coordinado en una secuencia definida.

➡ Conceptos genéricos de Workflow agénticos

➡ Topologías de Secuencias y Workflow

Workflow Secuencial

Workflow Tool

➡ Evaluaciones (Evals)

Descripción de la solución

Ejecución Local

La interfaz `create_harness(...)` y cómo podemos acceder

Ojo con el modelo: `Agent` crudo necesita una instancia de modelo