馃捇 Este es el inicio de una serie. Todo el c贸digo est谩 en un solo repo: resilient-agent-harness-sample-for-aws. Este post es la columna vertebral de chaos testing (00-agent-resilience-journey); los deep-dives a continuaci贸n desarrollan cada correcci贸n por completo. Clona el repo y sigue el paso a paso.

Netflix tiene una herramienta llamada Chaos Monkey que mata servidores en producci贸n, a prop贸sito, en horario laboral. Suena imprudente. Es lo contrario: si la ca铆da de una instancia aleatoria puede tumbar tu servicio, quieres enterarte en una prueba controlada un martes, no a las 3am durante un incidente real. Esa disciplina se llama chaos engineering, y es como se construyen sistemas distribuidos resilientes: asumes que las cosas van a fallar, as铆 que ensayas el fallo primero.

Los agentes de IA casi nunca reciben ese ensayo. Reciben una demo del camino feliz, un pulgar arriba y un deploy. Luego una herramienta se cuelga, una API devuelve basura, una llamada de red falla, y el agente, que nunca ha visto una herramienta rota, le dice al usuario con toda confianza que una tarea se complet贸 cuando en realidad no pas贸 nada.

La buena noticia: puedes aplicar la idea de Chaos Monkey a un agente ahora mismo, en unas pocas l铆neas de c贸digo. Strands Evals incluye chaos testing que inyecta fallos controlados en las herramientas durante la evaluaci贸n, para que encuentres las grietas en el arn茅s de tu agente antes de que producci贸n lo haga.

Esta es la columna vertebral de una serie. Cada correcci贸n tiene su propio post de deep-dive; este es el mapa y el diagn贸stico que los abre.

驴Cu谩l es la demo?

La demo es un agente de viajes, construido con Strands Agents, con tres herramientas que cada una toca el mundo exterior:

  • search_flights busca tarifas reales en el sandbox de Duffel.
  • get_weather consulta una API p煤blica de pron贸stico para el destino.
  • book_flight escribe una reserva en un ledger SQLite local (la "base de datos de referencia" contra la que verificamos).

Es un agente normal y peque帽o: busca, revisa el clima, reserva un viaje. En el camino feliz funciona perfecto, y ese es exactamente el problema. Para ver d贸nde realmente se rompe, tenemos que romper sus herramientas a prop贸sito.

驴Qu茅 es el chaos testing para agentes de IA?

El chaos testing inyecta fallos controlados (timeouts, errores de red, respuestas corruptas) en las llamadas a herramientas de un agente durante la evaluaci贸n, para medir c贸mo se comporta cuando su entorno se rompe en lugar de solo probar el camino feliz. Es la disciplina de Chaos Monkey aplicada a un agente: asumir que la herramienta va a fallar, hacerla fallar en una prueba, y verificar si el agente se recupera o al menos falla honestamente.

La idea clave: estamos endureciendo el arn茅s, no calificando al modelo. Los fallos y las correcciones son partes deterministas de la arquitectura del agente (hooks, una herramienta de respaldo, un evaluador de ground truth). Se comportan igual sin importar qu茅 modelo corre por dentro. La reacci贸n del modelo ante una herramienta rota var铆a entre ejecuciones, que es exactamente por qu茅 la resiliencia tiene que vivir en el arn茅s determinista alrededor del modelo, no en esperar que el modelo se las arregle.

Las dos formas en que una herramienta falla

Strands Evals te da dos familias de fallo, y rompen al agente de formas opuestas:

Familia Efectos Qu茅 pasa Qu茅 ve el agente
Pre-hook (cancela la llamada) Timeout, NetworkError, ExecutionError, ValidationError la herramienta se cancela antes de ejecutarse, as铆 que una escritura nunca persiste un error
Post-hook (corrompe el resultado) CorruptValues, TruncateFields, RemoveFields la herramienta se ejecuta (la escritura s铆 persiste), luego su respuesta se corrompe basura en la que puede confiar

Un fallo pre-hook es ruidoso: la herramienta da error, la base de datos queda vac铆a, f谩cil de detectar. Un fallo post-hook es silencioso y peligroso: la reserva realmente se guard贸, pero al agente le entregaron una confirmaci贸n rota y la reporta como 茅xito. Mismo agente, dos formas de fallo completamente diferentes, por eso diagnosticas antes de corregir.

Agregar chaos es una l铆nea

Construyes tu agente normalmente, luego agregas el plugin:

from strands import Agent
from strands_evals import Case
from strands_evals.chaos import ChaosCase, ChaosExperiment, ChaosPlugin, Timeout, CorruptValues
from strands_evals.eval_task_handler import TracedHandler, eval_task

# Nombra cada fallo: qu茅 efecto, en qu茅 herramienta.
effect_maps = {
    "book_timeout": {"tool_effects": {"book_flight": [Timeout()]}},
    "book_corrupt": {"tool_effects": {"book_flight": [CorruptValues(corrupt_ratio=1.0)]}},
}
cases = ChaosCase.expand([Case(name="trip", input=TRIP)], effect_maps,
                         include_no_effect_baseline=True)

@eval_task(TracedHandler())
def task(case):
    return Agent(model=MODEL, tools=TOOLS, plugins=[ChaosPlugin()],  # <- toda la configuraci贸n
                 system_prompt=PROMPT)

report = ChaosExperiment(cases=cases, evaluators=[...]).run_evaluations(task=task)
Enter fullscreen mode Exit fullscreen mode

ChaosPlugin() en plugins es todo el cableado. Inyecta el fallo de cada caso a trav茅s de los hooks nativos de tool-call de Strands. Sin mocks, sin parchear tus herramientas.

Diagnosticar, Corregir, Validar

La documentaci贸n de chaos estructura el trabajo como un ciclo, y la demo lo sigue en el agente de viajes de arriba. El diagrama muestra el ciclo completo: el ChaosPlugin inyecta fallos en las herramientas del agente, dos evaluadores punt煤an el resultado contra el ground truth para revelar d贸nde se rompe, agregas una correcci贸n por tipo de fallo, y luego toda la suite se re-ejecuta para confirmar que las correcciones se mantienen y nada regresion贸.

El ciclo Diagnosticar, Corregir, Validar: ChaosPlugin inyecta fallos en las herramientas del agente de viajes, dos evaluadores de ground truth muestran d贸nde se rompe, se agrega una correcci贸n por tipo de fallo, luego toda la suite se re-ejecuta para probar que las correcciones se mantienen y atrapar regresiones

Diagnosticar. Golpea al agente naive con los siete efectos en sus herramientas y punt煤a contra el ground truth (la base de datos) con dos evaluadores que tienen puntos ciegos diferentes: uno verifica "驴la reserva realmente persisti贸?", el otro verifica "驴el agente declar贸 una referencia de reserva que realmente existe?". Los fallos pre-hook aparecen como una base de datos vac铆a. Los post-hook son la trampa: la fila persisti贸 (as铆 que un check de solo-estado dice "pass") pero el agente report贸 una referencia rota. Dos evaluadores atrapan lo que uno no ver铆a.

Corregir, uno a la vez, emparejado con el fallo. Un retry gen茅rico no funciona, porque los fallos no tienen la misma forma:

  • Corrupci贸n silenciosa se convierte en un hook AfterToolCallEvent que re-lee el resultado contra la base de datos y lo reescribe con la verdad. (El patr贸n completo est谩 en el deep-dive 03 abajo.)
  • Una lectura con un segundo proveedor ca铆do (clima) se convierte en un hook BeforeToolCallEvent que conmuta a un proveedor genuinamente diferente. Un fallback real, porque dos APIs de clima realmente existen.
  • Un fallo sin camino de recuperaci贸n (b煤squeda ca铆da, sin respaldo) se convierte en conciencia de fallo en el prompt: hacer que el agente comunique honestamente en lugar de fabricar. El resultado correcto no es un 茅xito falso; es un honesto "no pude hacerlo."

Validar. Re-ejecuta toda la suite de chaos con las correcciones en su lugar. Este es el paso que se gana su lugar: no solo prueba que los casos que antes fallaban ahora pasan, atrapa una correcci贸n que regresion贸 otro caso. Nuestro primer prompt de conciencia de fallo accidentalmente hizo que el agente dejara de reservar cuando la herramienta de clima fallaba (0/4 vs 3/4 reservas). Solo ves eso re-ejecutando todo, no solo el caso que quer铆as corregir.

No todos los fallos "pasan", y ese es el punto

Cuando la escritura de reserva se cancela y el agente no tiene un segundo proveedor de reservas, el caso queda en rojo. Eso es honesto: es un gap estructural en el arn茅s, no un fallo del modelo. La correcci贸n tambi茅n es estructural: agregar un proveedor de respaldo y conmutar, exactamente como el ejemplo del clima. Una buena evaluaci贸n de resiliencia separa fallos recuperables de fallos irrecuperables-pero-honestos, para que sepas cu谩les necesitan una nueva pieza de arquitectura y cu谩les solo necesitan fallar limpiamente.

Los deep-dives: cada fallo, convertido en una demo completa

Esta ejecuci贸n de chaos revela fallos de herramientas en miniatura. Cada uno tiene su propio post que construye la cura por completo, en el mismo tipo de agente de viajes. El hilo que los une: un fallo que el modelo no puede auto-detectar, corregido determin铆sticamente en el arn茅s en vez de esperarlo en el prompt.

Preguntas frecuentes

驴El chaos testing es solo para Strands o AWS?
No. Inyecci贸n de fallos, hooks de tool-call, herramientas de respaldo y evaluaci贸n de ground truth son conceptos generales de agentes. Esta demo usa Strands Agents, que es agn贸stico al modelo: sus proveedores son intercambiables, as铆 que el mismo c贸digo corre en Amazon Bedrock (el default), Anthropic, OpenAI, o un modelo local v铆a Ollama. La demo usa OpenAI gpt-4o-mini por defecto porque solo necesita una API key para probar, aunque eso sigue siendo una llamada a la nube, no un modelo en tu m谩quina.

驴Por qu茅 medir la base de datos en vez de la respuesta del agente?
Porque un agente que escribe estado puede declarar 茅xito mientras los datos est谩n mal. Un check de estado atrapa los fallos ruidosos; un check de honestidad (驴la referencia que el agente declar贸 realmente existe?) atrapa la corrupci贸n silenciosa que un check de estado no ve.

驴Por qu茅 no simplemente reintentar cada herramienta fallida?
Un retry vuelve a golpear un fallo que est谩 activo durante todo el caso, y no se dispara en absoluto ante una corrupci贸n que devuelve "茅xito" con un payload malo. Empareja la correcci贸n con el tipo de fallo en lugar de eso.

驴Necesito infraestructura en vivo para que falle?
No, y ese es todo el valor. El chaos testing inyecta los fallos determin铆sticamente, as铆 que ensayas la ca铆da sin esperar una real.

M谩s sobre estos modos de fallo

Los deep-dives de arriba construyen cada cura por completo. Si quieres el panorama m谩s amplio, he escrito sobre varios de estos fallos por su cuenta en los 煤ltimos meses:

Ejec煤talo t煤 mismo

La demo completa de Diagnosticar, Corregir, Validar (un agente de viajes, siete efectos de chaos en tres herramientas, dos evaluadores de ground truth, y el antes/despu茅s de cada correcci贸n) corre de principio a fin en un solo notebook. Clona el repo y ejec煤talo:

git clone https://github.com/elizabethfuentes12/resilient-agent-harness-sample-for-aws.git
cd resilient-agent-harness-sample-for-aws/00-agent-resilience-journey

uv venv && source .venv/bin/activate
uv pip install -r requirements.txt

# Default: OpenAI gpt-4o-mini (solo necesitas una API key para probar)
cp .env.example .env   # luego llena OPENAI_API_KEY y un DUFFEL_API_KEY gratuito (app.duffel.com)
Enter fullscreen mode Exit fullscreen mode

Luego abre agent_resilience_journey.ipynb y ejec煤talo de arriba a abajo.

El patr贸n sigue a PALADIN (Sep 2025), que entrena agentes para recuperarse de fallos inyectados en herramientas. Las cifras de benchmark y la lectura completa est谩n en el README del repo. Esta demo reproduce el mecanismo (inyectar, medir, recuperar) con su propia salida determinista.

驴Cu谩l es el fallo que golpe贸 a tu agente en producci贸n: un timeout, una respuesta corrupta, una mentira con confianza? Cu茅ntame en los comentarios.

馃摤 驴Construyes agentes de IA confiables? Escribo sobre memoria de agentes, guardrails, evaluaci贸n y patrones multi-agente. Suscr铆bete a mi newsletter para recibir el siguiente.

隆Gracias! 馃嚮馃嚜
Dev.to
Linkedin
GitHub
Twitter
Instagram
Youtube