DEV Community: AWS Español

Cómo Prevenir Loops de Razonamiento en Agentes de IA y No Desperdiciar Tokens

Elizabeth Fuentes L — Thu, 28 May 2026 07:00:00 +0000

Los loops de razonamiento en agentes de IA ocurren cuando un agente llama a la misma herramienta repetidamente sin hacer progreso, convencido de que un intento más producirá la respuesta perfecta. El agente desperdicia tokens, tiempo y dinero sin entregar un resultado. Este post muestra cómo detectar y bloquear llamadas repetidas, validado con una demo donde herramientas ambiguas causaron 14 llamadas vs estados SUCCESS claros que se detuvieron en 2.

Esta demo usa Strands Agents. Los patrones (debounce hooks, estados claros de herramientas y límites de llamadas) son independientes del framework y aplican a cualquier agente que soporte hooks de ciclo de vida, incluyendo LangGraph, AutoGen y CrewAI.

Código funcional: github.com/aws-samples/sample-why-agents-fail

Serie: Por Qué Fallan los Agentes de IA

Desbordamiento de Ventana de Contexto — Patrón de Puntero de Memoria para datos grandes
Herramientas MCP Que Nunca Responden — Patrón asíncrono para APIs externas lentas
Loops de Razonamiento en Agentes de IA (este post) — Detectar y bloquear llamadas repetidas a herramientas

El Problema: Agentes Que Piensan Demasiado

Los loops de razonamiento en agentes de IA ocurren cuando un agente llama a la misma herramienta repetidamente sin hacer progreso, desperdiciando tokens y tiempo sin entregar un resultado. Los agentes de IA no solo fallan dando respuestas incorrectas; fallan al nunca terminar. Las investigaciones muestran que los agentes quedan atrapados en loops de razonamiento donde llaman a la misma herramienta repetidamente, convencidos de que "un paso más" producirá la respuesta perfecta.

The Decoder (Jan 2025) encontró que incluso con poder de cómputo ilimitado, pensar demasiado lleva a decisiones pobres. La comprensión incompleta del mundo causa errores compuestos. Cada paso de razonamiento adicional empeora las cosas, no las mejora.

Particula (Jul 2025) (observación comunitaria) documentó un caso extremo: un agente ejecutó 847 pasos de razonamiento a $47 por minuto y nunca entregó una respuesta final. Siguió refinando lógica, cuestionando conclusiones y solicitando más datos en un ciclo sin fin.

CodiesHub (Dec 2025) (observación comunitaria) identifica las causas raíz:

Objetivos poco claros — el agente no sabe cuándo está completa la tarea
Retroalimentación ambigua de herramientas — las herramientas no devuelven estados claros de éxito/fallo
Sin criterios de parada — sin límites duros en iteraciones o tiempo

Por Qué Ocurren los Loops: Retroalimentación Ambigua de Herramientas

La retroalimentación ambigua de herramientas ocurre cuando las herramientas devuelven resultados parciales o sugieren "puede haber más datos disponibles" sin estados terminales claros, causando que los agentes reintenten la misma llamada. Las herramientas que devuelven resultados parciales o sugieren "puede haber más datos disponibles" hacen que los agentes reintenten:

@tool
def search_flights(origin: str, destination: str, max_price: float) -> str:
    """Busca vuelos bajo un precio máximo."""
    prices = [random.randint(200, 800) for _ in range(3)]
    matching = [p for p in prices if p <= max_price]
    # El problema: "Puede haber más resultados disponibles" señala al LLM que reintente
    # El agente interpreta esto como "Debo buscar de nuevo para encontrar una mejor oferta"
    return (
        f"Se encontraron {len(matching)} vuelos bajo ${max_price} "
        f"(de {len(prices)} verificados). "
        "Nota: Puede haber más resultados disponibles. Los precios cambian frecuentemente."
    )

Esa "Nota: Puede haber más resultados disponibles" dispara el loop. El agente lo ve y piensa: "Tal vez si busco de nuevo, encontraré una mejor oferta." Reintenta con los mismos parámetros, obtiene resultados similares, y el ciclo continúa.

Solución 1: Debounce Hook con Strands

Los Strands Hooks interceptan el ciclo de vida del agente en cualquier punto. Un Debounce Hook usa BeforeToolCallEvent para detectar llamadas duplicadas antes de que se ejecuten:

from strands.hooks import HookProvider, BeforeToolCallEvent, BeforeInvocationEvent

class DebounceHook(HookProvider):
    def __init__(self, window_size=3):
        self.call_history = []       # Rastrea pares (tool_name, input)
        self.window_size = window_size  # Tamaño de ventana deslizante para detección de duplicados
        self.blocked_count = 0

    def register_hooks(self, registry):
        # BeforeInvocationEvent se dispara una vez al inicio de cada llamada agent.invoke()
        registry.add_callback(BeforeInvocationEvent, self.reset)
        # BeforeToolCallEvent se dispara antes de cada ejecución de herramienta — aquí interceptamos
        registry.add_callback(BeforeToolCallEvent, self.check_duplicate)

    def reset(self, event):
        # Limpia el historial al inicio de cada invocación para que los límites no se mezclen entre llamadas
        self.call_history = []

    def check_duplicate(self, event):
        # Construye una huella digital del nombre de herramienta + entradas exactas
        key = (event.tool_use["name"], str(event.tool_use["input"]))
        recent = self.call_history[-self.window_size:]

        if recent.count(key) >= 2:
            # cancel_tool es una API nativa de Strands que bloquea la ejecución y devuelve este mensaje al LLM
            event.cancel_tool = "BLOCKED: Llamada duplicada detectada"
            self.blocked_count += 1
            return

        self.call_history.append(key)

agent = Agent(tools=[search_flights], hooks=[DebounceHook()])

El hook rastrea las últimas 3 llamadas a herramientas. Si la misma herramienta con los mismos parámetros aparece dos veces, el tercer intento se bloquea vía event.cancel_tool, una API nativa de Strands que bloquea la ejecución de herramientas y devuelve un mensaje de error al LLM.

Solución 2: Estados SUCCESS/FAILED Claros

Las herramientas que devuelven estados terminales explícitos ayudan a los agentes a saber cuándo detenerse:

@tool
def book_hotel(hotel: str, guest: str, nights: int) -> str:
    """Reserva una habitación de hotel. Devuelve SUCCESS o FAILED claro.

    Returns:
        SUCCESS: Reserva confirmada con ID
        FAILED: Reserva fallida con razón
    """
    if random.random() > 0.15:
        conf = f"HT{random.randint(10000, 99999)}"
        price = random.randint(150, 350)
        return f"SUCCESS: Reserva {conf} confirmada — {guest} en {hotel}, {nights} noches, ${price * nights} total"
    return f"FAILED: {hotel} completamente reservado"

Cuando el agente recibe "SUCCESS: Reserva HT79265 confirmada", sabe que la tarea está hecha. Sin ambigüedad, sin llamadas extra.

Solución 3: Límites Duros con LimitToolCounts

CodiesHub recomienda: "Iteraciones, tokens, tiempo, gasto son no negociables." Strands proporciona LimitToolCounts en el Hooks Cookbook, un hook que limita llamadas a herramientas por invocación:

from strands.hooks import HookProvider, BeforeToolCallEvent, BeforeInvocationEvent
from threading import Lock

class LimitToolCounts(HookProvider):
    """Limita llamadas a herramientas por invocación. Del Strands Hooks Cookbook."""

    def __init__(self, max_tool_counts: dict[str, int]):
        # Presupuestos de llamadas por herramienta: {"search_flights": 2} significa máximo 2 búsquedas por invocación
        self.max_tool_counts = max_tool_counts
        self.tool_counts = {}
        self._lock = Lock()  # Thread-safe para llamadas concurrentes a herramientas en escenarios Swarm

    def register_hooks(self, registry):
        registry.add_callback(BeforeInvocationEvent, self.reset_counts)
        registry.add_callback(BeforeToolCallEvent, self.intercept_tool)

    def reset_counts(self, event):
        # Reinicia por invocación para que los límites apliquen por tarea, no por vida del agente
        with self._lock:
            self.tool_counts = {}

    def intercept_tool(self, event):
        tool_name = event.tool_use["name"]
        with self._lock:
            max_count = self.max_tool_counts.get(tool_name)
            count = self.tool_counts.get(tool_name, 0) + 1
            self.tool_counts[tool_name] = count

            if max_count and count > max_count:
                # Techo duro: bloquea la llamada y dice al LLM explícitamente que se detenga
                event.cancel_tool = f"Límite de herramienta '{tool_name}' alcanzado. NO LLAMAR MÁS."

# Aplica un límite duro de 2 búsquedas de vuelos por tarea de reserva — previene costos desbocados
limit_hook = LimitToolCounts(max_tool_counts={"search_flights": 2})
agent = Agent(tools=[search_flights], hooks=[limit_hook])

Incluso si el agente quiere buscar 10 veces, está limitado a 2. Techo duro, costos predecibles.

Resultados de la Demo

Probamos con un agente de reserva de viajes que busca vuelos y hoteles:

Escenario	Llamadas a Herramientas	Tiempo	Resultado
Retroalimentación Ambigua	14	21s	El agente reintentó orgánicamente — "los precios pueden cambiar" causó loops
DebounceHook	12	15s	Redujo reintentos pero alguna variación en parámetros
Estados SUCCESS Claros	2	4s	El agente se detuvo inmediatamente después de SUCCESS
LimitToolCounts	6 (2 bloqueadas)	6s	Techo duro aplicado — sin desborde

El contraste es dramático: 14 llamadas con herramientas ambiguas vs 2 llamadas con estados SUCCESS claros. Eso es una diferencia de 7x causada puramente por el diseño de retroalimentación de herramientas.

Cuándo Usar Cada Solución

DebounceHook — previene llamadas duplicadas con parámetros idénticos. Úsalo cuando las herramientas son idempotentes y reintentar con la misma entrada es desperdicio.

Estados SUCCESS/FAILED claros — la solución más simple. Diseña herramientas para devolver estados terminales explícitos. El agente sabe cuándo detenerse.

LimitToolCounts — techo duro en llamadas a herramientas por invocación. Úsalo en producción para prevenir costos desbocados independientemente del diseño de herramientas. Del Strands Hooks Cookbook.

Los tres juntos — defensa en profundidad. Estados claros previenen la mayoría de loops, debounce atrapa duplicados, y límites duros garantizan ejecución acotada.

Pruébalo Tú Mismo

Necesitas Python 3.9+, uv, y una clave API de OpenAI.

git clone https://github.com/aws-samples/sample-why-agents-fail
cd sample-why-agents-fail/stop-ai-agents-wasting-tokens/03-reasoning-loops-demo
uv venv && uv pip install -r requirements.txt
export OPENAI_API_KEY="tu-clave-aquí"

uv run python test_reasoning_loops.py   # Ejecuta los 4 escenarios

O abre test_reasoning_loops.ipynb en Jupyter, JupyterLab, VS Code, o tu entorno de notebook preferido.

Conclusiones Clave

La retroalimentación ambigua de herramientas causa loops orgánicos — "puede haber más resultados disponibles" hace que los agentes reintenten
14 llamadas vs 2 llamadas — estados SUCCESS claros reducen llamadas en 7x en nuestra demo
Los hooks interceptan antes de la ejecución — BeforeToolCallEvent.cancel_tool bloquea la llamada antes de que la herramienta se ejecute. El DebounceHook son ~30 líneas de código
Los límites duros son obligatorios — cada agente necesita topes en iteraciones, tiempo y gasto
Se documentaron 847 pasos a $47/min (Particula, observación comunitaria) — agentes sin límites queman dinero sin entregar respuestas

Preguntas Frecuentes

¿Por qué los agentes de IA repiten la misma llamada a herramienta?

Los agentes repiten llamadas a herramientas cuando las respuestas de herramientas contienen retroalimentación ambigua como "puede haber más resultados disponibles" o "los precios cambian frecuentemente." El LLM interpreta estas señales como una razón para reintentar, esperando resultados diferentes o mejores. Sin estados terminales claros (SUCCESS/FAILED), el agente no tiene forma de saber que la tarea está completa.

¿Qué es un DebounceHook y cómo previene loops de razonamiento?

Un DebounceHook rastrea llamadas recientes a herramientas en una ventana deslizante. Cuando la misma herramienta se llama con parámetros idénticos más que un umbral establecido (típicamente 2 veces dentro de una ventana de 3), el hook bloquea la llamada usando event.cancel_tool antes de que la herramienta se ejecute. El LLM recibe un mensaje "BLOCKED: Llamada duplicada" y debe intentar un enfoque diferente. En Strands Agents, esto son aproximadamente 30 líneas de código usando la API de HookProvider.

¿Cómo reducen los estados SUCCESS/FAILED claros las llamadas a herramientas?

Cuando una herramienta devuelve "SUCCESS: Reserva HT79265 confirmada," el LLM reconoce que la tarea está completa y deja de llamar a esa herramienta. Respuestas ambiguas como "Se encontraron 2 vuelos, puede haber más disponibles" carecen de esta señal, causando que el agente reintente. En nuestra demo, estados claros redujeron las llamadas a herramientas de 14 a 2, una mejora de 7x.

Referencias

Investigación

Language models can overthink — The Decoder, Jan 2025
How many reasoning steps do AI agents need — Particula (observación comunitaria), Jul 2025
How to Prevent Infinite Loops and Spiraling Costs — CodiesHub (observación comunitaria), Dec 2025

Implementación

Strands Hooks — Lifecycle event interception and tool cancellation

Gracias!

🇻🇪🇨🇱 Dev.to Linkedin GitHub Twitter Instagram Youtube

Elizabeth Fuentes LFollow

I help developers build production-ready AI applications through hands-on tutorials and open-source projects.

CLI vs MCP: guía para agentes en producción

ricardoceci — Wed, 27 May 2026 13:49:46 +0000

Una de las preguntas más interesantes que me hicieron en la última clase de mi curso "Strands Agents + AgentCore: De Cero a Agentes en Producción".

Ayer, en medio de la clase, llegó la pregunta:

"Ricardo, estoy viendo en Twitter y LinkedIn una pelea entre CLI y MCP para tools. ¿Cuál usamos? ¿Es verdad que MCP se come el contexto?"

La pregunta no es trivial. Tiene impacto directo en costos, latencia, confiabilidad y arquitectura de cualquier agente que llevemos a producción. La respuesta corta: no hay una respuesta única. Hay un framework de decisión que la comunidad fue construyendo en los últimos meses.

En este post te cuento qué está pasando, por qué se generó el debate, y cómo decidir en cada caso.

¿Qué son MCP y CLI?

MCP (Model Context Protocol)

Lo lanzó Anthropic en noviembre de 2024 como un estándar abierto para conectar agentes a herramientas externas (GitHub, Slack, bases de datos, lo que sea). La promesa fue clara: el "USB-C de la IA", un protocolo único para que cualquier modelo hable con cualquier herramienta sin reinventar la integración cada vez.

A mayo de 2026, MCP es el estándar de facto. La Linux Foundation lo gobierna a través de la Agentic AI Foundation, hay más de 177,000 tools registradas y casi 100 millones de descargas mensuales del SDK.

CLI (Command-Line Interface)

La interfaz de línea de comandos existe desde 1971 en Unix. Son los comandos de toda la vida: git, gh, kubectl, docker, aws, ffmpeg. No es tecnología nueva. Es la interfaz más veterana del desarrollo de software, y eso, sorprendentemente, resultó ser una ventaja enorme para los modelos de lenguaje grandes (LLMs).

El problema que detonó el debate: MCP devora contexto

A fines de 2025 y principios de 2026, los developers que pusieron MCP en producción empezaron a notar algo grave: MCP consume una cantidad enorme de tokens antes de que el agente haga una sola cosa útil.

El ejemplo concreto

Cuando conectás el servidor MCP de GitHub, este inyecta el esquema completo de herramientas en la ventana de contexto del modelo:

{
  "tools": [
    {
      "name": "create_issue",
      "description": "Create a new issue...",
      "inputSchema": { ... }
    }
    // ... y se repite para ~90 herramientas más
  ]
}

El servidor MCP de GitHub tiene del orden de 93 herramientas, lo que se traduce en ~55,000 tokens consumidos solo en definiciones, antes de que el agente reciba el primer prompt útil.

Con 3 servidores MCP conectados (GitHub + Slack + tu base de datos), podés llegar a consumir el 70%+ de una ventana de contexto de 200K tokens solo en metadata.

Anthropic mismo lo reconoció

En noviembre de 2025, Adam Jones y Conor Kelly del equipo de Engineering de Anthropic publicaron "Code execution with MCP: Building more efficient agents", donde reconocen el problema explícitamente:

"As MCP usage scales, there are two common patterns that can increase agent cost and latency: tool definitions overload the context window, and intermediate tool results consume additional tokens."

Cuando los creadores del protocolo te dicen "sí, hay un problema", no es polémica de Twitter. Es una corrección de arquitectura real.

La chispa: Peter Steinberger y OpenClaw

El debate explotó en febrero de 2026 cuando Peter Steinberger, creador de OpenClaw (el agente open source que pasó de 0 a 190,000 stars de GitHub en pocas semanas y terminó con Steinberger fichado por OpenAI), tiró una frase que se hizo viral:

"MCP was a mistake. Bash is better."

Steinberger no estaba haciendo clickbait. Su tesis era pragmática: los LLMs ya saben usar bash de memoria porque los entrenaron con miles de millones de líneas de scripts, Stack Overflow y man pages. No hace falta enseñarles un protocolo nuevo cuando ya hablan el viejo a la perfección.

⚠️ Disclaimer importante: OpenClaw también fue protagonista de uno de los desastres de seguridad más sonados del 2026 (ClawHavoc Attack, registrado como Common Vulnerabilities and Exposures CVE-2026-25253, miles de instancias expuestas en internet). El argumento técnico de Steinberger sobre CLI vs MCP es sólido, pero su modelo de seguridad fue criticado duramente por Cisco, Gartner y Meta. Es importante separar las dos cosas.

Las tres voces que estructuraron el debate

1. David Zhang (Duet) y el "trilemma"

David Zhang, construyendo Duet, describió el dilema imposible que enfrentó al integrar MCP, incluso después de haber resuelto OAuth y client registration dinámico:

Cargar todo al inicio → perdés memoria de trabajo para razonamiento.
Limitar integraciones → el agente solo habla con pocos servicios.
Cargar herramientas dinámicamente → agregás latencia y middleware complejo. Lo bautizó el "trilemma de MCP". Su decisión: sacó MCP completamente y adoptó CLI + ejecución de código.

2. Cobus Greyling y la tesis del "puente que ya existe"

En Replace MCP With CLI (Feb 2026), Greyling escribió la frase que mejor sintetiza el argumento pro-CLI:

"Con MCP, construís el puente hacia la herramienta. Con CLI, el puente ya existe."

Todo servicio serio ya tiene su CLI: AWS, GCP, Azure, GitHub, Stripe, Twilio, Kubernetes. Son production-grade, los mantienen los proveedores, y los modelos los conocen sin que les expliques nada.

3. Anthropic y el contraataque: Code Execution with MCP

Anthropic no se quedó callada. En noviembre 2025 publicó una solución intermedia muy elegante: en lugar de pedirle al modelo que llame tools una por una vía MCP, el agente escribe código corto que llama esas tools por debajo en un sandbox.

El resultado, según sus propios benchmarks, es una reducción de hasta el 98% de tokens consumidos (pasaron de 150,000 tokens a 2,000 tokens en su ejemplo de prueba).

Hay implementaciones en producción que ya validaron ese resultado: 70,000 → 800 tokens (~98% de reducción) en agentes reales sobre GitHub.

¿Por qué CLI funciona tan bien para LLMs?

Cuatro razones técnicas que vale la pena entender:

1. Los LLMs ya saben usar CLI "de memoria"

El modelo no necesita que le expliques qué hace git log --oneline -10. Lo vio millones de veces en su entrenamiento. Con MCP, cada esquema es nuevo para el modelo y tiene que interpretarlo en runtime.

# CLI: el modelo ya sabe esto
docker ps --filter "status=running" --format "{{.Names}}: {{.Status}}"

// MCP: el modelo recibe esto y tiene que interpretarlo
{
  "name": "list_containers",
  "inputSchema": {
    "properties": {
      "status_filter": { "enum": ["running", "stopped", "all"] },
      "format_fields": { "type": "array" }
    }
  }
}

2. CLI tiene "divulgación progresiva" gratis

Un agente con CLI puede ir descubriendo herramientas a medida que las necesita:

aws --help                          # ¿qué servicios hay?
aws s3 --help                       # ¿qué puedo hacer con S3?
aws s3 cp --help                    # ¿cómo se usa cp exactamente?

Cada llamada consume pocos tokens y solo cuando el agente realmente necesita esa información. MCP, por contraste, carga todo el esquema antes del primer mensaje.

3. Composabilidad tipo Unix

# Pipeline real que un agente puede armar solo
aws ec2 describe-instances --query 'Reservations[].Instances[?State.Name==`running`].InstanceId' \
  --output text | \
  xargs -I {} aws cloudwatch get-metric-statistics --instance-id {}

Hacer esto vía MCP requiere coordinar múltiples llamadas estructuradas, parsear resultados intermedios, mantener estado. Bash lo hace en una línea.

4. Cero overhead de protocolo

CLI: genera comando → ejecuta → lee output. Directo.

- MCP: `negocia capacidades → carga esquemas → construye llamada → servidor ejecuta → wrap del resultado → parse`. Cada paso suma tokens.

La comparación honesta: ¿cuándo gana cada uno?

Criterio	CLI ✅	MCP ✅
Eficiencia de tokens	⭐⭐⭐⭐⭐	⭐⭐
Herramientas locales (git, docker, kubectl)	Ideal	Innecesario
Datos externos en tiempo real (Salesforce, Notion)	Limitado	Ideal
Ecosistemas multi-agente / multi-tenant	Difícil	Diseñado para eso
Auth compleja (OAuth multi-tenant)	Limitado	Nativo
Herramientas sin API (ffmpeg, pandoc, jq)	Única opción	No aplica
Confiabilidad en tareas complejas	Alta (local)	Variable
Prototipado rápido	⭐⭐⭐⭐⭐	⭐⭐
Integraciones empresariales gobernadas	Limitado	✅

El framework de decisión que se puede implementar

Este es el árbol de decisión que valdria la pena utilizar:

1. ¿Existe un CLI maduro para esta tarea y el modelo ya lo conoce?
       ↓ SÍ → USÁ CLI
       ↓ NO → ¿Necesitás datos externos en tiempo real
                vía API de terceros con OAuth?
                    ↓ SÍ → USÁ MCP (o llamada directa a la API)
                    ↓ NO → ¿Es operación multi-agente / multi-tenant
                            con permisos granulares por servidor?
                                ↓ SÍ → USÁ MCP
                                ↓ NO → Considerá construir un CLI interno

Un consejo adicional: si vas a usar MCP, considerá seriamente el patrón Code Execution que propone Anthropic. Reduce el consumo de contexto al mínimo y podés seguir disfrutando del ecosistema MCP sin pagar el costo de cargar todos los esquemas upfront.

Lo que realmente está pasando: no es una guerra, es una corrección

Mi lectura, después de haber investigado un poco mas:

🔴 MCP fue sobrevendido como solución universal en 2025 → resultó costoso para muchas tareas cotidianas.
🟢 CLI fue subestimado por ser "viejo" → resultó perfecto para agentes porque los LLMs ya lo conocen.
🟡 El futuro es híbrido: CLI para operaciones locales y determinísticas, MCP para datos externos y multi-tenant, Code Execution para pipelines complejos. La frase viral "MCP is dead" es más una corrección de hype que una muerte real. Lo que murió fue la idea de que MCP tiene que ser el único puente entre los agentes y el mundo exterior.

¿Qué hacemos en el curso?

En "Strands Agents + AgentCore: De Cero a Agentes en Producción" construimos un Corporate Travel Agent con enfoque híbrido:

CLI / SDK directo: para operaciones locales, herramientas internas, y APIs simples (como Open-Meteo para clima).
MCP: cuando necesitamos un protocolo gobernado para integraciones empresariales (Duffel para reservas con OAuth).
DynamoDB SDK nativo: porque para state management no tiene sentido envolver todo en MCP. La regla mental que me funciona: MCP es como Kubernetes. Fenomenal cuando lo necesitás, sobredimensionado cuando no.

Seguilo Aqui: https://www.ricardoceci.dev

Preguntas frecuentes

¿MCP está muerto?

No. MCP es el estándar de facto, gobernado por la Linux Foundation, con casi 100 millones de descargas mensuales. Lo que murió es la idea de que MCP debe ser el único puente entre agentes y herramientas. Para muchos casos cotidianos, CLI es más eficiente.

¿Cuándo conviene MCP sobre CLI?

Tres casos claros: (1) integraciones empresariales con OAuth multi-tenant, (2) ecosistemas multi-agente que necesitan gobierno centralizado, (3) servicios externos sin CLI maduro. Para todo lo demás (git, docker, kubectl, aws, manipulación local), CLI gana en tokens y latencia.

¿Es seguro darle bash a un agente?

Es la pregunta correcta. La respuesta es: depende del sandbox. Steinberger demostró el peligro con el incidente ClawHavoc en OpenClaw. La práctica recomendada es ejecutar el agente en contenedores con permisos restringidos, whitelist de comandos, y revisión humana para operaciones destructivas.

¿El patrón Code Execution reemplaza a MCP?

No, lo complementa. Code Execution te permite usar MCP servers existentes pero cargar solo las tools necesarias bajo demanda y procesar resultados intermedios sin pasarlos por la ventana de contexto. Es lo mejor de ambos mundos para integraciones complejas.

¿Cómo afecta esto a Strands Agents, LangChain, CrewAI?

Todos los frameworks principales soportan ambos patrones. La decisión es por herramienta, no por framework. En Strands Agents podés mezclar Agent(tools=[tu_funcion_python, mcp_client.tools]) sin problema.

Recursos para profundizar

¿Tu agente está sufriendo de context overflow? ¿Qué patrón estás usando vos? Dejame un comentario, me interesa saber cómo está resolviendo cada uno este trade-off en producción.

Cómo Evaluar Agentes IA: Tutorial de LLM-as-Judge

Elizabeth Fuentes L — Tue, 26 May 2026 19:03:38 +0000

Evalúa la calidad de agentes IA con LLM-as-Judge y análisis de trayectorias. Detecta fallos silenciosos, tokens desperdiciados y alucinaciones antes de producción. Tutorial en Python con código.

Tu agente IA acaba de devolver "BA117 a las 7PM ($450)" - respuesta correcta, calificación 5 estrellas. Lo que no viste: hizo 3 llamadas API innecesarias y alucinó una verificación de precio. Las métricas tradicionales de pasa/falla calificaron esto como "perfecto".

Este es el problema de los fallos silenciosos. Los agentes IA devuelven respuestas plausibles mientras realizan llamadas API innecesarias, alucina hechos, o siguen caminos de razonamiento inseguros. Las métricas binarias no detectan nada de esto.

Este artículo cubre las dos técnicas fundamentales de evaluación que todo agente necesita: LLM-as-Judge para calidad de salida y Evaluación de Trayectorias (el camino paso a paso que toma un agente) para calidad de proceso. Estas forman la base para detectar alucinaciones, evaluar el uso de herramientas, alineación de seguridad y optimización de costos - temas cubiertos en posts posteriores de esta serie.

¿Por qué Strands Agents? Usamos Strands para los ejemplos de código porque proporciona captura automática de trayectorias mediante hooks y un SDK de evaluación dedicado (strands-agents-evals), facilitando demostrar estos patrones. Las técnicas de evaluación mostradas aquí aplican a cualquier framework de agentes - LangGraph, AutoGen, o implementaciones personalizadas.

Sobre el código: Todos los ejemplos provienen del repositorio how-to-evaluate-ai-agents-sample-for-aws - notebooks Jupyter ejecutables con Strands Agents y AWS Bedrock. Cada notebook es autocontenido con explicaciones y ejemplos funcionales.

Lo que aprenderás:

Cómo implementar evaluación LLM-as-Judge con rúbricas explícitas (configuración en 5 min)
Por qué la evaluación de trayectorias detecta fallos que las métricas de solo salida no capturan
Ejemplos de código en Python usando Strands Agents en AWS Bedrock
Cómo usar los evaluadores integrados de Amazon Bedrock AgentCore para producción
Investigación más reciente de abril de 2026 (WindowsWorld, D3-Gym, framework CARE)

🔗 Ver todos los ejemplos de código en GitHub

Tiempo estimado de lectura: 9 minutos

¿Por Qué Strands Agents Para Evaluar Agentes IA?

Strands Agents proporciona el kit de herramientas de evaluación más completo para agentes IA en producción - combinando captura automática de trayectorias, SDK de evaluación dedicado e integración con AWS Bedrock en un solo framework.

Ventajas clave para evaluación:

SDK de evaluación dedicado (strands-agents-evals) con evaluadores integrados para calidad de salida y puntuación de trayectorias
Organización de suites de pruebas - clases Experiment y Case para ejecutar múltiples escenarios de prueba con generación automática de reportes
Captura automática de trayectorias mediante hooks (HookProvider) - cada llamada a herramienta se registra con estado de éxito/fallo, sin instrumentación manual
Nativo en AWS Bedrock - funciona perfectamente con Claude, Llama y Mistral mediante perfiles de inferencia multi-región, eliminando gestión de claves API
Flexibilidad de modelos - los evaluadores pueden usar cualquier modelo (GPT-4o, Claude Sonnet, etc.) independiente del modelo del agente
Visualización integrada - reports[0].display() muestra resultados formateados instantáneamente, perfecto para notebooks Jupyter
Puntuación ponderada - combina múltiples evaluadores (ej., 60% calidad de salida + 40% trayectoria) para evaluación completa
OpenTelemetry integrado - trazas distribuidas automáticas compatibles con Datadog, Honeycomb y otras plataformas de observabilidad

Por Qué Fallan Las Métricas Binarias

Considera estos dos agentes respondiendo "Encuentra vuelos de NYC a Londres":

	Agente A	Agente B
Respuesta	"BA117 a las 7PM ($450), DL1 a las 9:30PM ($520)"	"BA117 a las 7PM ($450), DL1 a las 9:30PM ($520)"
Llamadas a Herramientas	`search_flights("NYC", "London")`	`search_flights("NYC", "London")` `get_currency_exchange()` `search_flights("NYC", "London")` (duplicado)
Pasa/Falla	✅ Pasa	✅ Pasa

Ambos producen la respuesta correcta. La puntuación pasa/falla los califica por igual. Pero el Agente B desperdició tokens en una herramienta irrelevante y una llamada duplicada. La evaluación de trayectorias detecta esto. La evaluación de solo salida no.

¿Cómo Funciona la Evaluación LLM-as-Judge?

LLM-as-Judge usa un modelo de lenguaje grande para puntuar salidas de agentes contra criterios definidos, reemplazando la revisión manual. Proporciona puntuaciones continuas (0.0-1.0) con explicaciones, a diferencia del pasa/falla binario. La investigación muestra que rúbricas explícitas con umbrales de puntuación (0.8-1.0 = excelente, 0.5-0.7 = adecuado) producen evaluación consistente y reproducible a escala.

Paper: Autorubric (Marzo 2026)

El Problema con Prompts Vagos

La mayoría de los jueces LLM usan prompts vagos como "¿Es esta una buena respuesta?" Esto produce puntuaciones impredecibles porque el juez decide qué significa "buena". La investigación muestra que rúbricas vagas conducen a sesgo de posición (preferir la primera opción) y sesgo de verbosidad (preferir respuestas más largas).

La Solución: Criterios de Puntuación Explícitos

Define umbrales exactos de puntuación en tu rúbrica:

from strands_evals import Experiment, Case
from strands_evals.evaluators import OutputEvaluator

# Define explicit scoring criteria
evaluator = OutputEvaluator(
    rubric=(
        "Rate the travel agent response on a 0 to 1 scale:\n"
        "- 0.8-1.0: Lists specific flights with airline, flight number, times, and price\n"
        "- 0.5-0.7: Provides some useful information but missing key details\n"
        "- 0.2-0.4: Vague response without actionable information\n"
        "- 0.0-0.1: Contains fabricated information or is completely unhelpful"
    ),
    model="gpt-4o-mini",  # Or use AWS Bedrock: us.anthropic.claude-sonnet-4-20250514-v1:0
)

# Create test cases
cases = [
    Case(name="good", input="Find flights NYC to London", 
         expected_output="Specific flights with details"),
    Case(name="vague", input="Find flights NYC to London",
         expected_output="Specific flights with details"),
]

# Run evaluation
def task(case):
    if case.name == "good":
        return "BA117 at 7PM ($450), DL1 at 9:30PM ($520)"
    return "There are several flights available. Prices vary."

experiment = Experiment(cases=cases, evaluators=[evaluator])
reports = experiment.run_evaluations(task)
reports[0].display()

Salida:

good:  Score 0.95 - Lists specific flights with all required details
vague: Score 0.30 - Missing specific details about airlines and times

Rúbricas Vagas vs Específicas: Una Comparación

El paper Autorubric muestra que la calidad de la rúbrica impacta directamente la confiabilidad de las puntuaciones. Pruébalo tú mismo:

# Vague rubric (produces unreliable scores)
vague_evaluator = OutputEvaluator(
    rubric="Is this a good response?",
    model="gpt-4o-mini",
)

# Specific rubric (produces reliable scores)
specific_evaluator = OutputEvaluator(
    rubric=(
        "Rate 0-1:\n"
        "0.8-1.0: Lists specific flights with airline, number, times, price\n"
        "0.5-0.7: Some useful info but missing key details\n"
        "0.2-0.4: Vague without actionable information\n"
        "0.0-0.1: Contains fabricated information"
    ),
    model="gpt-4o-mini",
)

# Compare on 3 test cases: good, mediocre, hallucinated
responses = {
    "good": "BA117 at 7PM ($450), DL1 at 9:30PM ($520), VS001 at 11PM ($480)",
    "mediocre": "There are several flights available. Prices vary.",
    "hallucinated": "Take AeroFast Premium with our award-winning service.",
}

Resultados:

Vague rubric:
  good: 0.70 | mediocre: 0.50 | hallucinated: 0.60  (spread: 0.20)

Specific rubric:
  good: 0.90 | mediocre: 0.30 | hallucinated: 0.10  (spread: 0.80)

La rúbrica específica produce 4x más separación de puntuaciones, haciendo posible establecer umbrales de calidad significativos.

Mezclando Jueces LLM con Verificaciones Determinísticas

Usa jueces LLM para calidad subjetiva y verificaciones determinísticas para requisitos estrictos:

from strands_evals.evaluators import OutputEvaluator, Contains, ToolCalled

experiment = Experiment(
    cases=cases,
    evaluators=[
        OutputEvaluator(rubric="..."),      # LLM judge: subjective quality
        Contains(value="$"),                 # Deterministic: must mention price
        ToolCalled(tool_name="search_flights"),  # Deterministic: must search
    ],
)

Por qué esto importa: Las verificaciones determinísticas se ejecutan instantáneamente a costo cero. Úsalas para requisitos que pueden verificarse con coincidencia de cadenas (contiene "$", comienza con "Error:", llama a herramienta específica) y jueces LLM para evaluación de calidad que requiere entender contexto.

Hallazgos Clave de la Investigación

El paper Grading Scale (Enero 2026) probó escalas de puntuación desde binaria (0/1) hasta 10 puntos y encontró:

Escala 0-5 produce el alineamiento humano-LLM más fuerte (correlación de Pearson 0.89)
Las escalas de 10 puntos introducen ruido sin mejorar precisión
Las escalas binarias pierden 73% de graduaciones de calidad

Recomendación: Usa una escala 0-5 (mapeada a 0.0-1.0 en código) con criterios explícitos en cada nivel.

¿Qué Es la Evaluación de Trayectorias?

La evaluación de trayectorias puntúa el camino paso a paso que toma un agente para alcanzar una solución, no solo la respuesta final. Detecta llamadas duplicadas a herramientas, acciones irrelevantes y pasos intermedios inseguros que la evaluación de solo salida no captura. Al capturar la secuencia de invocaciones de herramientas, identifica patrones de razonamiento desperdiciados o peligrosos antes de que lleguen a producción.

Paper: TRACE (Febrero 2026)

El Problema: La Evaluación de Solo Salida Está Ciega

La evaluación de solo salida ve la respuesta final. No puede detectar:

Llamadas duplicadas a herramientas (tokens desperdiciados)
Llamadas irrelevantes a herramientas (camino de razonamiento incorrecto)
Pasos intermedios inseguros (violaciones de privacidad, acciones no autorizadas)
Orden ilógico de herramientas (get_price antes de search_product)

La Solución: Evalúa el Camino, No Solo el Destino

La evaluación de trayectorias puntúa el camino paso a paso que tomó el agente:

from strands_evals.evaluators import TrajectoryEvaluator

traj_eval = TrajectoryEvaluator(
    rubric=(
        "Rate the tool usage trajectory 0-1:\n"
        "- 0.8-1.0: Only relevant tools called, no duplicates, logical order\n"
        "- 0.5-0.7: Mostly correct but minor inefficiency\n"
        "- 0.2-0.4: Irrelevant tools called or excessive duplicates\n"
        "- 0.0-0.1: Completely wrong tool selection"
    ),
    model="gpt-4o-mini",
)

# Simulate Agent A (efficient) and Agent B (wasteful)
efficient_trajectory = [
    {"name": "search_flights", "args": {"origin": "NYC", "dest": "London"}},
    {"name": "get_weather", "args": {"city": "London"}},
]

wasteful_trajectory = [
    {"name": "search_flights", "args": {"origin": "NYC", "dest": "London"}},
    {"name": "get_currency_exchange", "args": {}},  # irrelevant
    {"name": "search_flights", "args": {"origin": "NYC", "dest": "London"}},  # duplicate
    {"name": "get_weather", "args": {"city": "London"}},
]

cases = [
    Case(name="efficient", input="Find flights and weather", 
         expected_trajectory=["search_flights", "get_weather"]),
    Case(name="wasteful", input="Find flights and weather",
         expected_trajectory=["search_flights", "get_weather"]),
]

def traj_task(case):
    trajectory = efficient_trajectory if case.name == "efficient" else wasteful_trajectory
    return {"output": "BA117 at 7PM, London is 18C", "trajectory": trajectory}

exp = Experiment(cases=cases, evaluators=[traj_eval])
reports = exp.run_evaluations(traj_task)
reports[0].display()

Salida:

efficient: Score 0.95 - Clean trajectory, only relevant tools
wasteful:  Score 0.25 - Contains irrelevant tool and duplicate call

Captura Automática de Trayectorias con Hooks

En producción, no construyes trayectorias manualmente. Usa Strands hooks para capturarlas automáticamente:

from strands import Agent
from strands.hooks import HookProvider, HookRegistry
from strands.hooks.events import AfterToolCallEvent

class TrajectoryPlugin(HookProvider):
    def __init__(self):
        self.trajectory = []

    def on_after_tool_call(self, event: AfterToolCallEvent):
        self.trajectory.append({
            "name": event.tool_use.name,
            "args": event.tool_use.parameters,
            "success": event.exception is None,
        })

tracker = TrajectoryPlugin()
agent = Agent(model="gpt-4o-mini", tools=[...], hooks=[tracker])

# Run the agent
result = agent("Find flights from NYC to London")

# The hook captured everything automatically
print(f"Trajectory: {tracker.trajectory}")
# Output: [{'name': 'search_flights', 'args': {...}, 'success': True}, ...]

Por qué esto importa: Los Strands hooks se ejecutan en cada llamada a herramienta sin configuración. El trazado OpenTelemetry está integrado, dándote trazas distribuidas automáticamente.

Investigación Reciente: ¿Qué Hay de Nuevo en Abril de 2026?

Tres papers publicados este mes avanzan la metodología de evaluación:

1. D3-Gym: Tareas Científicas Ejecutables

Paper: arXiv:2604.27977 (30 de Abril, 2026)

Publicó 565 tareas científicas con entornos ejecutables. Hallazgo clave: 87.5% de concordancia entre evaluación automatizada y estándares de oro anotados por humanos.

Implicación: LLM-as-Judge puede igualar la calidad de evaluación humana cuando las rúbricas están bien definidas y la verdad fundamental es verificable.

2. WindowsWorld: Benchmark de Agentes GUI

Paper: arXiv:2604.27776 (30 de Abril, 2026)

Probó agentes GUI en 181 tareas profesionales multi-aplicación. Resultado: <21% tasa de éxito en tareas multi-app.

Implicación: Incluso los agentes de última generación fallan frecuentemente en tareas complejas de múltiples pasos. La evaluación debe detectar estos fallos antes de producción.

3. CARE: Ingeniería Colaborativa de Razonamiento de Agentes

Paper: arXiv:2604.28043 (30 de Abril, 2026)

Propone metodología con puertas de etapa con compuertas de verificación en cada etapa de desarrollo. Involucra expertos en la materia, desarrolladores y agentes auxiliares.

Implicación: La evaluación no es un paso final—debe ocurrir en cada etapa del desarrollo del agente.

Amazon Bedrock AgentCore: Evaluación Lista para Producción

Si estás desplegando agentes en producción en AWS, Amazon Bedrock AgentCore proporciona capacidades integradas de evaluación y observabilidad diseñadas específicamente para flujos de trabajo de agentes.

Evaluadores Integrados

AgentCore ofrece 13 evaluadores integrados que usan LLMs como jueces:

Evaluador	Lo Que Mide
`Builtin.Helpfulness`	Utilidad y claridad de la respuesta
`Builtin.GoalSuccessRate`	Si el agente logró el objetivo del usuario
`Builtin.Correctness`	Exactitud factual de las respuestas
`Builtin.ToolSelection`	Calidad de selección de herramientas/grupos de acción

Observabilidad

AgentCore proporciona captura de trazas y registro integrados para monitoreo de producción.

Cuándo Usar AgentCore vs Strands Evaluation

Escenario	Usar AgentCore	Usar Strands Evals
Agentes en producción en AWS Bedrock	✅	✅ (compatible)
Evaluación CI/CD antes de despliegue	✅	✅
Comparación multi-modelo (GPT, Claude, Gemini)	❌	✅
Lógica de evaluación personalizada (APIs externas, regex)	✅ (Lambda)	✅ (Python)
Trazado sin configuración	✅	⚠️ (requiere hooks)

Recomendación: Usa evaluadores integrados de AgentCore para monitoreo de producción y Strands Evals para pruebas pre-despliegue y comparaciones multi-framework.

Aprende más:

Combinando LLM-as-Judge y Evaluación de Trayectorias

La evaluación lista para producción usa ambas técnicas:

Escenario	Usar LLM-as-Judge	Usar Eval de Trayectorias
Agente devuelve respuesta incorrecta	✅ Lo detecta	✅ Puede detectar camino ilógico
Agente devuelve respuesta correcta por camino incorrecto	❌ No lo detecta	✅ Lo detecta
Agente hace paso intermedio inseguro	❌ No lo detecta	✅ Lo detecta
Salida del agente no es profesional/grosera	✅ Lo detecta	❌ No lo detecta

Recomendación: Ejecuta ambos evaluadores en paralelo. Usa LLM-as-Judge para calidad de salida, evaluación de trayectorias para calidad de proceso.

from strands_evals import Experiment

experiment = Experiment(
    cases=cases,
    evaluators=[
        output_evaluator,     # Scores output quality
        trajectory_evaluator,  # Scores process quality
    ],
)

reports = experiment.run_evaluations(task)

# Access both scores
output_score = reports[0].overall_score
trajectory_score = reports[1].overall_score

# Combine scores (weighted average)
final_score = 0.6 * output_score + 0.4 * trajectory_score

Pruébalo Tú Mismo

Prerrequisitos:

Python 3.10+
OPENAI_API_KEY o acceso a AWS Bedrock

Instalar:

pip install strands-agents strands-agents-evals boto3

Ejecutar las demos:

git clone https://github.com/elizabethfuentes12/how-to-evaluate-ai-agents-sample-for-aws.git
cd how-to-evaluate-ai-agents-sample-for-aws

# LLM-as-Judge demo
cd evaluate-with-llm-judges/01-rubric-based-evaluation
jupyter notebook 01-rubric-based-evaluation.ipynb

# Trajectory evaluation demo
cd ../../evaluate-agent-trajectories/01-trajectory-scoring
jupyter notebook 01-trajectory-scoring.ipynb

Usuarios de AWS Bedrock: Reemplaza gpt-4o-mini con:

from strands.models.bedrock import BedrockModel

model = BedrockModel(model_id="us.anthropic.claude-sonnet-4-20250514-v1:0")

Preguntas Frecuentes

¿Cómo elijo entre LLM-as-Judge y verificaciones determinísticas?

Usa verificaciones determinísticas para requisitos estrictos que pueden verificarse con coincidencia de cadenas o regex. Usa LLM-as-Judge para calidad subjetiva que requiere entender el contexto.

Ejemplo: "Debe mencionar un precio" → verificación determinística. "¿Es la respuesta útil?" → LLM-as-Judge.

¿Qué pasa si mi agente usa más de 50 herramientas? ¿Escala la evaluación de trayectorias?

Sí. La evaluación de trayectorias examina la secuencia de llamadas a herramientas, no detalles individuales de cada herramienta. Una trayectoria de 50 llamadas sigue siendo una sola llamada API al LLM juez.

Costo por evaluación: ~$0.001-0.003 (GPT-4o-mini) o $0.015-0.045 (Claude Sonnet).

¿Puedo usar evaluación de trayectorias con LangGraph o AutoGen?

Sí. La evaluación de trayectorias solo requiere la lista de llamadas a herramientas como entrada. Captúralas con .get_graph().get_state() de LangGraph o el historial de mensajes de AutoGen, luego pásalas a TrajectoryEvaluator.

¿Con qué frecuencia debo ejecutar evaluaciones?

CI/CD: Ejecuta en cada commit con una suite pequeña de pruebas (10-20 casos)
Staging: Ejecuta suite completa (100-500 casos) antes del despliegue a producción
Producción: Muestrea 1-5% del tráfico en vivo y evalúa de manera asíncrona

Puntos Clave

Las métricas binarias pierden 73% de graduaciones de calidad. Usa puntuación continua (0.0-1.0) con rúbricas explícitas.
La evaluación de trayectorias detecta problemas que la evaluación de solo salida no capta: llamadas duplicadas, herramientas irrelevantes, pasos inseguros.
La escala 0-5 produce el alineamiento humano-LLM más fuerte (0.89 correlación de Pearson). Mapea a 0.0-1.0 en código.
Los hooks de Strands capturan trayectorias automáticamente mediante AfterToolCallEvent. No se necesita instrumentación manual.
Combina ambas técnicas. LLM-as-Judge para calidad de salida, evaluación de trayectorias para calidad de proceso.

¿Qué Sigue?

Este post cubrió los fundamentos de evaluación - LLM-as-Judge y análisis de trayectorias. Estas técnicas forman la base para patrones de evaluación más profundos.

Siguiente en esta serie:

Parte 3: Detectando Fallos de Agentes3-detecting-failures.md) - Detección de alucinaciones sin ejemplos previos con métricas LSC, monitoreo de seguridad a nivel de trayectoria y barreras en tiempo real con hooks de Strands
Parte 4: Métricas de Producción4-production-metrics.md) - Compensaciones costo-calidad con índice compuesto KAMI, validación de corrección de herramientas y observabilidad de AWS Bedrock AgentCore

Todos los ejemplos de código están en el repositorio de GitHub con notebooks Jupyter ejecutables.

Referencias

Autorubric: Unifying Rubric-based LLM Evaluation (Rao & Callison-Burch, Marzo 2026)
TRACE: Trajectory-Aware Comprehensive Evaluation (Febrero 2026)
Grading Scale paper (Enero 2026)
D3-Gym: Real-World Verifiable Environments (30 de Abril, 2026)
WindowsWorld: GUI Agent Benchmark (30 de Abril, 2026)
CARE: Collaborative Agent Reasoning (30 de Abril, 2026)
Strands Agents Documentation
Strands Evaluation SDK

Gracias!

🇻🇪🇨🇱 Dev.to Linkedin GitHub Twitter Instagram Youtube

Elizabeth Fuentes LFollow

I help developers build production-ready AI applications through hands-on tutorials and open-source projects.

De DJ local a DJ con Spotify: tools externos y multi-agente

Hazel Saenz — Thu, 21 May 2026 17:22:55 +0000

Tu agente ya sabe de música. Ahora va a controlar Spotify, crear playlists reales y delegar a sub-agentes especializados.

En el artículo anterior construimos un agente DJ desde cero. Cuatro capas: un modelo que habla, herramientas para buscar en una biblioteca local, múltiples tools que el modelo orquesta solo, y memoria para recordar tus gustos entre sesiones.

Todo local. Todo open source. Todo en tu laptop.

Pero hay un problema.

Tu biblioteca local tiene 30 canciones. Spotify tiene más de 100 millones. Tu agente puede recomendar jazz para trabajar, pero no puede reproducir esa canción en tu parlante. Puede armar una playlist en texto, pero no puede crearla en tu cuenta.

Un agente que solo consulta datos locales es útil. Un agente que controla servicios reales es poderoso.

Y aquí es donde se pone interesante: ¿qué pasa cuando un solo agente no es suficiente? ¿Cuando necesitas un especialista en emociones, otro en eventos, y otro en gustos personales? La respuesta es un patrón que suena complejo pero es elegante: agent as a tool.

En este artículo vamos a construir las capas 5 y 6 del DJ:

Capa 5: Tools que se conectan a una API externa real (Spotify)
Capa 6: Un agente orquestador que delega a sub-agentes especializados

El flujo completo se ve así: tú le hablas al agente, el agente razona con Bedrock, invoca tools que llaman a Spotify, y la música suena en tu dispositivo.

Lo que necesitas para seguir este artículo

No necesitas haber implementado las capas anteriores. Este artículo es autocontenido, puedes clonar el repo y correr las capas 5 y 6 directamente. Pero sí te recomiendo leer el artículo anterior para entender los conceptos de @tool, agent loop y model-driven que usamos aquí.

git clone https://github.com/hsaenzG/OpenSource-agents-demo.git
cd OpenSource-agents-demo
python3 -m venv .venv
source .venv/bin/activate
pip install 'strands-agents' spotipy python-dotenv

Lo que necesitas:

Python 3.10+
Una cuenta de Spotify Developer, para conectar con la API
AWS CLI configurado con acceso a Amazon Bedrock, porque vamos a usar un modelo en la nube

¿Por qué Bedrock y no Ollama? En el artículo anterior usamos llama3.1:8b corriendo local, y funciona bien con 1-2 tools. Pero las capas 5 y 6 tienen 7-8 herramientas cada una. Para tool-calling confiable con muchas herramientas, necesitas un modelo más capaz. Amazon Bedrock con Nova Pro resuelve eso, y como vimos antes, cambiar de proveedor es cambiar una línea de código gracias a la abstracción del SDK.

Capa 5: El DJ controla Spotify

El concepto: tools que llaman APIs externas

Hasta ahora, nuestros tools eran funciones puras. buscar_canciones() filtra un JSON local. analizar_energia() hace cálculos sobre datos en memoria. No salen de tu proceso de Python.

Pero un @tool puede hacer cualquier cosa que Python pueda hacer. Incluyendo llamar APIs externas.

La mecánica es la misma: decoras una función con @tool, escribes un docstring claro, y el modelo decide cuándo invocarla. La diferencia es que dentro de esa función, en vez de filtrar un JSON, haces un HTTP request a un servicio externo.

Fíjate: para el modelo, no hay diferencia entre un tool local y uno que llama a Spotify. El modelo ve el tool spec (nombre, descripción, parámetros) y decide si lo necesita. No sabe ni le importa si por dentro es un json.load() o un requests.get(). Esa es la elegancia del patrón.

Configurar Spotify Developer

Antes del código, necesitas credenciales. Crea una app en el Spotify Developer Dashboard:

Click en Create App
Nombre: lo que quieras (ej: "DJ Agent")
Redirect URI: http://127.0.0.1:8000/callback
Marca Web API
Guarda el Client ID y Client Secret

Crea un archivo .env en la raíz del proyecto:

SPOTIFY_CLIENT_ID=TU-CLIENT-ID
SPOTIFY_CLIENT_SECRET=TU-CLIENT-SECRET

Nota: La primera vez que ejecutes el script, se abrirá el navegador para autorizar la app con tu cuenta de Spotify. Después, el token se cachea automáticamente y no necesitas volver a autorizar.

La conexión con Spotify

Usamos spotipy, una librería de Python que envuelve la Spotify Web API con OAuth2:

from strands import Agent, tool
from strands.models import BedrockModel
import json
import os
from dotenv import load_dotenv
import spotipy
from spotipy.oauth2 import SpotifyOAuth

load_dotenv()

sp = spotipy.Spotify(
    auth_manager=SpotifyOAuth(
        client_id=os.getenv("SPOTIFY_CLIENT_ID"),
        client_secret=os.getenv("SPOTIFY_CLIENT_SECRET"),
        redirect_uri="http://127.0.0.1:8000/callback",
        scope="playlist-modify-public,playlist-modify-private,user-library-read,user-top-read,user-modify-playback-state,user-read-playback-state",
    )
)

usuario = sp.current_user()
print(f"✅ Conectado a Spotify como: {usuario['display_name']}")

El scope define qué permisos tiene tu app. Necesitamos leer tu biblioteca, crear playlists, y controlar la reproducción. Spotify usa OAuth2, el estándar de la industria para autorización delegada.

El primer tool externo: buscar en Spotify

@tool
def buscar_en_spotify(query: str, limite: int = 10) -> str:
    """Busca canciones en Spotify por nombre, artista o género.
    SIEMPRE usa esta herramienta cuando el usuario pregunte por canciones o artistas.
    Los resultados son datos REALES y actualizados de Spotify.

    Args:
        query: Texto de búsqueda (ej: "Shakira", "rock alternativo", "Bad Bunny último")
        limite: Número máximo de resultados (default: 10)
    """
    resultados = sp.search(q=str(query), type="track", limit=min(limite, 10))
    tracks = resultados["tracks"]["items"]

    if not tracks:
        return f"No encontré canciones en Spotify para: {query}"

    canciones = []
    for t in tracks:
        canciones.append({
            "titulo": t["name"],
            "artista": t["artists"][0]["name"],
            "album": t["album"]["name"],
            "uri": t["uri"],
            "duracion_min": round(t["duration_ms"] / 60000, 1),
        })

    return json.dumps(canciones, ensure_ascii=False, indent=2)

¿Qué está pasando aquí? La estructura es idéntica a buscar_canciones del artículo anterior. Misma firma: recibe parámetros, devuelve un string JSON. Mismo decorador @tool. Mismo docstring descriptivo.

La diferencia está dentro: en vez de filtrar BIBLIOTECA, llama a sp.search() que hace un HTTP GET a https://api.spotify.com/v1/search. El resultado viene con datos reales: URIs de Spotify, duración exacta, álbum, fecha de lanzamiento.

Y fíjate en el uri. Ese spotify:track:xxx es lo que necesitamos para reproducir o agregar a playlists. Es el identificador único de cada canción en Spotify.

Reproducir música: el agente toma acción real

Aquí es donde el agente deja de ser un "recomendador" y se convierte en un controlador:

@tool
def reproducir_cancion(nombre_cancion: str, artista: str = "") -> str:
    """Reproduce una canción en el dispositivo activo de Spotify del usuario.
    Busca la canción por nombre y la reproduce automáticamente.

    Requiere que Spotify esté abierto en algún dispositivo (celular, computadora, etc.).

    Args:
        nombre_cancion: Nombre de la canción a reproducir
        artista: Nombre del artista (opcional, ayuda a encontrar la correcta)
    """
    dispositivos = sp.devices()
    if not dispositivos["devices"]:
        return ("No hay dispositivos activos de Spotify. "
                "Abre Spotify en tu celular o computadora e intenta de nuevo.")

    # Buscar la canción
    query = f"track:{nombre_cancion}"
    if artista:
        query += f" artist:{artista}"
    resultados = sp.search(q=query, type="track", limit=5)
    tracks = resultados["tracks"]["items"]

    if not tracks:
        return f"No encontré '{nombre_cancion}' en Spotify."

    track = tracks[0]
    device_id = next(
        (d["id"] for d in dispositivos["devices"] if d["is_active"]),
        dispositivos["devices"][0]["id"]
    )

    sp.start_playback(device_id=device_id, uris=[track["uri"]])

    return json.dumps({
        "status": "reproduciendo",
        "cancion": track["name"],
        "artista": track["artists"][0]["name"],
        "mensaje": f"▶️ Reproduciendo: {track['name']} — {track['artists'][0]['name']}",
    }, ensure_ascii=False)

Esto es un tool que modifica estado en el mundo real. Cuando el modelo lo invoca, tu parlante empieza a sonar. No es un mock, no es una simulación. Es la API de Spotify ejecutando PUT /v1/me/player/play.

Crear playlists reales

@tool
def crear_playlist_en_spotify(nombre: str, descripcion: str, canciones_uris: list) -> str:
    """Crea una playlist en la cuenta de Spotify del usuario con las canciones indicadas.

    Args:
        nombre: Nombre de la playlist (ej: "Viernes de Rock", "Cena Romántica")
        descripcion: Descripción breve de la playlist
        canciones_uris: Lista de URIs de Spotify o nombres de canciones
    """
    if not canciones_uris:
        return "No me diste canciones para agregar a la playlist."

    # Resolver URIs — si no es una URI válida, buscar la canción
    uris_validas = []
    for item in canciones_uris:
        item = str(item).strip()
        if item.startswith("spotify:track:"):
            uris_validas.append(item)
        else:
            r = sp.search(q=item, type="track", limit=1)
            tracks = r["tracks"]["items"]
            if tracks:
                uris_validas.append(tracks[0]["uri"])

    if not uris_validas:
        return "No pude encontrar ninguna de las canciones en Spotify."

    # Crear la playlist
    playlist = sp.user_playlist_create(
        user=sp.current_user()["id"],
        name=str(nombre),
        public=False,
        description=str(descripcion)
    )

    # Agregar canciones (en batches de 100, límite de la API)
    for i in range(0, len(uris_validas), 100):
        sp.playlist_add_items(playlist["id"], uris_validas[i:i + 100])

    return json.dumps({
        "status": "ok",
        "mensaje": f"Playlist '{nombre}' creada con {len(uris_validas)} canciones",
        "url": playlist["external_urls"]["spotify"],
    }, ensure_ascii=False)

Fíjate en un detalle importante: el tool acepta tanto URIs (spotify:track:xxx) como nombres de canciones. Si el modelo pasa nombres en vez de URIs, el tool los resuelve buscando en Spotify. Esto hace al tool más robusto, el modelo no necesita recordar URIs exactas entre llamadas.

Conocer al usuario: top artistas y canciones

@tool
def mis_top_artistas(periodo: str = "medium_term") -> str:
    """Obtiene los artistas más escuchados del usuario en Spotify.

    Args:
        periodo: "short_term" (último mes), "medium_term" (6 meses), "long_term" (siempre)
    """
    resultados = sp.current_user_top_artists(limit=10, time_range=periodo)
    artistas = []
    for a in resultados["items"]:
        artistas.append({
            "nombre": a["name"],
            "generos": a["genres"][:3],
            "popularidad": a["popularity"],
        })
    return json.dumps(artistas, ensure_ascii=False, indent=2)


@tool
def mis_top_canciones(periodo: str = "medium_term") -> str:
    """Obtiene las canciones más escuchadas del usuario en Spotify.

    Args:
        periodo: "short_term" (último mes), "medium_term" (6 meses), "long_term" (siempre)
    """
    resultados = sp.current_user_top_tracks(limit=20, time_range=periodo)
    canciones = []
    for t in resultados["items"]:
        canciones.append({
            "titulo": t["name"],
            "artista": t["artists"][0]["name"],
            "uri": t["uri"],
        })
    return json.dumps(canciones, ensure_ascii=False, indent=2)

Estos tools le dan al agente algo que la memoria local no puede: datos reales de comportamiento. No es lo que el usuario dice que le gusta, es lo que realmente escucha. Esa diferencia importa cuando armas recomendaciones.

El agente completo de la Capa 5

modelo = BedrockModel(model_id="us.amazon.nova-pro-v1:0", region_name="us-east-1")

dj = Agent(
    model=modelo,
    system_prompt="""Eres un DJ personal conectado a Spotify. Controlas la música del usuario.

    REGLAS:
    1. SIEMPRE usa buscar_en_spotify antes de recomendar música.
    2. NUNCA inventes canciones, artistas o datos.
    3. Para reproducir: usa reproducir_cancion con el nombre.
    4. Para crear playlists: usa crear_playlist_en_spotify con las URIs.
    5. Basa TODAS tus respuestas en datos reales de las herramientas.

    Respondes en español, con onda y buen gusto musical.""",
    tools=[
        buscar_en_spotify,
        crear_playlist_en_spotify,
        reproducir_cancion,
        mis_top_artistas,
        mis_top_canciones,
    ],
)

# Conversación interactiva
while True:
    mensaje = input("🎵 Tú: ").strip()
    if mensaje.lower() in ("salir", "exit"):
        break
    print("\n🎧 DJ: ", end="", flush=True)
    dj(mensaje)
    print("\n")

Ahora puedes decirle "ponme algo de Daft Punk" y tu parlante empieza a sonar. Puedes decirle "arma una playlist de jazz para cenar" y aparece en tu cuenta de Spotify. Datos reales, acciones reales.

Nota: Necesitas una cuenta premium para tener acceso a la API de Spotify.

El salto conceptual: de tool local a tool externo

Hagamos una pausa para entender qué acaba de pasar.

En la Capa 2 del artículo anterior, un tool era esto:

@tool
def buscar_canciones(genero: str = "") -> str:
    """Busca canciones en la biblioteca local."""
    resultados = [c for c in BIBLIOTECA if genero.lower() in c["genero"].lower()]
    return json.dumps(resultados)

En la Capa 5, un tool es esto:

@tool
def buscar_en_spotify(query: str) -> str:
    """Busca canciones en Spotify."""
    resultados = sp.search(q=query, type="track", limit=10)
    return json.dumps(resultados["tracks"]["items"])

Misma interfaz. Misma mecánica. Diferente poder.

Para el agente, ambos son iguales: una función que recibe parámetros y devuelve un string. El modelo no sabe (ni necesita saber) si por dentro hay un filtro de lista o un HTTP request con OAuth2.

Eso significa que puedes conectar tu agente a cualquier API con el mismo patrón:

Un @tool que consulta tu base de datos de producción
Un @tool que envía emails via SendGrid
Un @tool que crea tickets en Jira
Un @tool que despliega código en AWS

El patrón es siempre el mismo: función Python + decorador @tool + docstring claro = el modelo decide cuándo usarlo.

Capa 6: Multi-agente: el DJ delega

El problema: un agente que hace demasiado

La Capa 5 funciona. Pero tiene un system prompt largo, 7-8 tools, y tiene que manejar situaciones muy diferentes:

"Recomiéndame algo de rock" → necesita conocer tus gustos
"Arma una playlist de 3 horas para una fiesta" → necesita planificar duración y energía
"Estoy triste, ponme algo" → necesita entender emociones y mapearlas a música

Un solo agente puede hacer todo eso. Pero entre más responsabilidades le das, más largo es el system prompt, más tools tiene que considerar, y más probable es que se confunda.

La solución no es un agente más grande. Es varios agentes especializados.

El concepto: Agent as a Tool

Y aquí viene el patrón más elegante de este artículo.

¿Recuerdas que un @tool puede hacer cualquier cosa que Python pueda hacer? Incluyendo... invocar otro agente.

@tool
def consultar_dj_personal(mensaje: str) -> str:
    """Delega al DJ Personal: experto en gustos musicales y recomendaciones.

    Args:
        mensaje: El mensaje del usuario para el DJ Personal
    """
    respuesta = dj_personal(mensaje)
    return str(respuesta)

Eso es todo. Un agente completo, con su propio system prompt, sus propios tools, su propia personalidad, expuesto como un @tool de otro agente.

El agente que tiene estos tools se llama orquestador. No busca canciones, no crea playlists. Su único trabajo es entender qué necesita el usuario y decidir a cuál especialista delegarle.

Los sub-agentes especializados

Cada sub-agente tiene un rol claro y un conjunto de tools específico:

modelo = BedrockModel(model_id="us.amazon.nova-pro-v1:0", region_name="us-east-1")

dj_personal = Agent(
    model=modelo,
    system_prompt="""Eres un DJ personal experto. Conoces los gustos del usuario.
    SIEMPRE usa buscar_en_spotify antes de recomendar. NUNCA inventes datos.
    Puedes consultar mis_top_artistas y mis_top_canciones para conocer al usuario.""",
    tools=[buscar_en_spotify, crear_playlist_en_spotify, reproducir_cancion,
           mis_top_artistas, mis_top_canciones],
    callback_handler=None,  # Silenciar output
)

dj_eventos = Agent(
    model=modelo,
    system_prompt="""Eres un DJ profesional de eventos. Armas playlists para fiestas,
    bodas, cenas. Verificas que la duración cubra el evento completo.""",
    tools=[buscar_en_spotify, crear_playlist_en_spotify, reproducir_cancion,
           planificar_evento],
    callback_handler=None,
)

dj_emocional = Agent(
    model=modelo,
    system_prompt="""Eres un DJ empático especializado en emociones y música.
    Primero analizas la emoción, luego buscas música que la acompañe.
    Eres sensible y no juzgas.""",
    tools=[buscar_en_spotify, crear_playlist_en_spotify, reproducir_cancion,
           analizar_emocion],
    callback_handler=None,
)

Fíjate en callback_handler=None. Eso silencia el output de los sub-agentes, solo el orquestador habla con el usuario. Los sub-agentes trabajan en silencio y devuelven su resultado al orquestador.

Cada sub-agente tiene:

Un system prompt enfocado en su especialidad
Solo los tools que necesita (no todos los disponibles)
Una personalidad diferente (el emocional es empático, el de eventos es profesional)

Los tools del orquestador: agentes como herramientas

@tool
def consultar_dj_personal(mensaje: str) -> str:
    """Delega al DJ Personal: experto en gustos musicales y recomendaciones.
    Úsalo cuando el usuario quiera recomendaciones, descubrir música nueva,
    o pida algo basado en sus gustos.

    Args:
        mensaje: El mensaje completo del usuario para el DJ Personal
    """
    respuesta = dj_personal(mensaje)
    return str(respuesta)


@tool
def consultar_dj_eventos(mensaje: str) -> str:
    """Delega al DJ de Eventos: experto en armar playlists para ocasiones específicas.
    Úsalo cuando el usuario mencione un evento, fiesta, boda, cena,
    o pida una playlist con duración específica.

    Args:
        mensaje: El mensaje completo del usuario para el DJ de Eventos
    """
    respuesta = dj_eventos(mensaje)
    return str(respuesta)


@tool
def consultar_dj_emocional(mensaje: str) -> str:
    """Delega al DJ Emocional: experto en música y estados de ánimo.
    Úsalo cuando el usuario exprese cómo se siente o quiera música
    para acompañar un estado de ánimo.

    Args:
        mensaje: El mensaje completo del usuario para el DJ Emocional
    """
    respuesta = dj_emocional(mensaje)
    return str(respuesta)

El docstring de cada tool-agente es clave. Le dice al orquestador cuándo usar cada uno. "Cuando el usuario exprese cómo se siente" → DJ Emocional. "Cuando mencione un evento" → DJ Eventos. El modelo del orquestador lee estos docstrings y decide a quién delegar.

El orquestador: el punto de entrada

orquestador = Agent(
    model=modelo,
    system_prompt="""Eres el DJ principal. Tu trabajo es entender qué necesita el usuario
    y delegarlo al sub-agente especializado correcto.

    Tienes 3 DJs especializados:
    1. consultar_dj_personal: Recomendaciones basadas en gustos
    2. consultar_dj_eventos: Playlists para eventos con duración específica
    3. consultar_dj_emocional: Música para estados de ánimo

    REGLAS:
    - SIEMPRE delega al sub-agente apropiado.
    - Pasa el mensaje COMPLETO del usuario.
    - Si no estás seguro, usa consultar_dj_personal como default.
    - Presenta la respuesta del sub-agente de forma natural.""",
    tools=[consultar_dj_personal, consultar_dj_eventos, consultar_dj_emocional,
           reproducir_cancion, reproducir_playlist],
)

El orquestador también tiene reproducir_cancion y reproducir_playlist directamente. Si el usuario dice "ponme Bohemian Rhapsody", no necesita delegar a nadie, puede reproducir directamente.

Cómo funciona en la práctica

🎵 Tú: Estoy triste, ponme algo suave

🎧 DJ: [internamente: invoca consultar_dj_emocional("Estoy triste, ponme algo suave")]
       [DJ Emocional: invoca analizar_emocion("triste")]
       [DJ Emocional: invoca buscar_en_spotify("indie folk acoustic")]
       [DJ Emocional: invoca reproducir_cancion("Skinny Love", "Bon Iver")]

       Entiendo. Te puse "Skinny Love" de Bon Iver — indie folk suave,
       perfecto para este momento. Si quieres, puedo armar una playlist
       completa con ese mood.

El usuario habla con un solo agente. No sabe que detrás hay tres especialistas. No necesita elegir un menú. El orquestador decide, delega, y presenta la respuesta como si fuera suya.

¿Por qué no un solo agente con todos los tools?

Podrías meter todos los tools en un solo agente con un system prompt gigante. Funcionaría... a veces. Pero:

Aspecto	Un solo agente	Multi-agente
System prompt	Largo, genérico	Corto, enfocado por especialista
Tools por agente	10+ (confunde al modelo)	4-5 por especialista
Personalidad	Una sola para todo	Diferente por contexto
Debugging	Difícil saber qué falló	Sabes exactamente qué agente falló
Escalabilidad	Agregar tools degrada calidad	Agregas un nuevo sub-agente

El patrón multi-agente no es sobre complejidad. Es sobre separación de responsabilidades. El mismo principio que usas en microservicios, aplicado a agentes.

El código completo

El código completo de ambas capas está en el repo:

# Capa 5 — Spotify
python capa5_spotify.py

# Capa 6 — Multi-agente
python capa6_multi_agente.py

Repo: github.com/hsaenzG/OpenSource-agents-demo

Nota: Sin Spotify configurado, las capas 5-6 funcionan con la biblioteca local como fallback. Verás un aviso ⚠️ Spotify no disponible pero el agente seguirá respondiendo.

Lo que aprendiste

Un @tool puede hacer cualquier cosa que Python pueda hacer, incluyendo llamar APIs externas con OAuth2, crear recursos en servicios reales, y controlar dispositivos
Para el modelo, no hay diferencia entre un tool local y uno externo. La interfaz es la misma: función + decorador + docstring
El patrón agent as a tool permite crear sistemas multi-agente donde un orquestador delega a especialistas
Los sub-agentes se silencian con callback_handler=None, solo el orquestador habla con el usuario
Separar responsabilidades en agentes especializados mejora la calidad de las respuestas y facilita el debugging

Qué sigue

Con 6 capas, tienes un agente que habla, busca, razona, recuerda, controla servicios externos, y delega a especialistas. Todo con Python, Strands Agents y APIs abiertas.

Si quieres ir más allá:

Documentación de Strands Agents — guías, ejemplos, y API reference
Multi-agent patterns en Strands — swarms, graphs, y más patrones de orquestación
Repo del demo — el código completo de las 6 capas
Spotipy — la librería de Python para Spotify
Spotify Developer Dashboard — para crear tu app

¿Te resultó útil este artículo? Compártelo con tu equipo o déjame saber en los comentarios qué API te gustaría conectar a tu agente. Y si ya estás construyendo agentes multi-agente o conectando APIs externas, me encantaría escuchar tu experiencia.

Solucionar Timeouts de MCP: Patrón HandleId Asíncrono

Elizabeth Fuentes L — Thu, 21 May 2026 07:00:00 +0000

Las herramientas MCP congelan a los agentes de IA cuando las APIs externas son lentas, causando errores 424. El patrón handleId asíncrono devuelve inmediatamente un ID de trabajo y consulta los resultados sin bloquear.

El timeout de herramienta MCP ocurre cuando un agente de IA llama a una herramienta del Protocolo de Contexto de Modelo (MCP) que depende de una API externa lenta. La herramienta bloquea al agente indefinidamente en lugar de devolver un error. El resultado es un error 424 (Failed Dependency) o un flujo de trabajo congelado sin retroalimentación al usuario. Este post muestra el problema con escenarios reales y cómo el patrón handleId asíncrono proporciona respuestas inmediatas.

Esta demo usa Strands Agents con MCP (Model Context Protocol). El patrón asíncrono es independiente del framework y aplica a cualquier agente que llame APIs externas a través de MCP.

Código funcional: github.com/aws-samples/sample-why-agents-fail

Serie: Por Qué Fallan los Agentes de IA

Desbordamiento de Ventana de Contexto — Patrón de Puntero de Memoria para datos grandes
Herramientas MCP Que Nunca Responden (este post) — Patrón asíncrono para APIs externas lentas
Loops de Razonamiento en Agentes de IA — Detectar y bloquear llamadas repetidas a herramientas

El Problema: Herramientas MCP Que Nunca Responden

El Protocolo de Contexto de Modelo (MCP) permite a los agentes de IA llamar herramientas externas. Pero cuando esas herramientas dependen de APIs lentas, todo el flujo de trabajo del agente se congela. El agente espera. El usuario espera. No pasa nada.

Una observación comunitaria de Octopus (Resilient AI Agents With MCP, 2025) identifica el problema central: a medida que aumentan las integraciones de sistemas externos, también aumenta la probabilidad de fallo. Los sistemas dejan de estar disponibles, responden lentamente o devuelven errores. Los agentes no tienen una estrategia incorporada para manejar esto.

Los reportes de OpenAI Community confirman el impacto del mundo real:

Errores 424 cuando las herramientas MCP tardan demasiado
Estados sin respuesta donde las solicitudes ni tienen éxito ni fallan
Herramientas que pasan la validación de handshake pero hacen timeout durante la ejecución

Por Qué Sucede Esto

MCP espera que las herramientas respondan rápidamente. Cuando una herramienta llama a una API externa lenta.

El protocolo MCP tiene expectativas de timeout implícitas. Si la herramienta no responde dentro de ~7-10 segundos, la conexión puede caerse con un error 424 (Failed Dependency). El agente recibe un error en lugar de datos, y el usuario no obtiene una respuesta útil.

Tres modos de fallo:

API lenta — La herramienta espera 15+ segundos, UX pobre pero eventualmente responde
API fallida — Servicio externo no disponible, error 424 después del timeout
Estado sin respuesta — Solicitud aceptada pero nunca devuelve, requiere reinicio de sesión

La Demo: Simulando Escenarios Reales de Timeout

Construimos un servidor MCP que simula estos escenarios del mundo real:

from mcp.server import FastMCP
import asyncio

# FastMCP es un framework ligero de servidor MCP — las herramientas se registran con @mcp.tool()
mcp = FastMCP("Timeout Demo Server")

# Línea base: responde en 1s, bien dentro del umbral de timeout implícito de MCP (~7-10s)
@mcp.tool(description="Fast API - responds in 1 second")
async def fast_api(query: str) -> str:
    await asyncio.sleep(1)
    return f"Fast result for: {query}"

# Caso problema: retraso de 15s excede timeout de MCP — el agente se congela esperando esto
@mcp.tool(description="Slow API - responds in 15 seconds")
async def slow_api(query: str) -> str:
    await asyncio.sleep(15)  # Simula un servicio externo lento (pipeline de datos, trabajo por lotes)
    return f"Slow result for: {query}"

# Caso de fallo: retraso de 7s activa el timeout, luego lanza Failed Dependency (424)
@mcp.tool(description="Failing API - returns 424 after delay")
async def failing_api(query: str) -> str:
    await asyncio.sleep(7)
    raise Exception("Failed Dependency: External service unavailable")

La Solución Async HandleId

En lugar de esperar operaciones lentas, devuelve inmediatamente con un ID de seguimiento:

import uuid

# Almacén de trabajos en memoria: mapea job_id → {status, query, result}
# Para producción, reemplazar con un almacén persistente (Redis, DynamoDB) para durabilidad entre reinicios
JOBS = {}

# El patrón handleId: devuelve un ID de seguimiento inmediatamente en lugar de bloquear
@mcp.tool(description="Start a long-running job, returns immediately with job ID")
async def start_async_job(query: str) -> str:
    job_id = str(uuid.uuid4())[:8]  # ID corto que el LLM puede pasar en llamadas de seguimiento
    JOBS[job_id] = {"status": "processing", "query": query}

    # Fire-and-forget: el trabajo lento se ejecuta en segundo plano, la herramienta devuelve antes de que termine
    asyncio.create_task(do_work(job_id, query))

    # El agente recibe esto en < 1s — sin timeout, sin UI congelada
    return f"Job started: {job_id}. Use check_job_status to poll for results."

# Endpoint de consulta: el agente llama a esto repetidamente hasta que el estado es "completed"
@mcp.tool(description="Check status of a running job")
async def check_job_status(job_id: str) -> str:
    job = JOBS.get(job_id)
    if not job:
        return f"Job {job_id} not found"
    if job["status"] == "completed":
        return f"COMPLETED: {job['result']}"  # Devuelve el resultado real al agente
    return f"PROCESSING: Job {job_id} still running"  # El agente consulta de nuevo después de una breve espera

Resultados de la Demo

Probamos los cuatro escenarios con un Strands Agent conectado al servidor MCP:

Escenario	Tiempo de Respuesta	Experiencia de Usuario	Hallazgo de Investigación
Fast API (retraso 1s)	3.2s total	✅ Buen UX	Línea base
Slow API (retraso 15s)	17.8s total	❌ UX pobre — agente espera	Octopus: "el agente espera indefinidamente"
Failing API (424)	7.7s total	❌ Error después de esperar	OpenAI Community: errores 424
Patrón asíncrono (handleId)	3.7s total	✅ Respuesta inmediata	Solución: "responder ASAP con handleId"

El patrón asíncrono transforma una espera de 17.8s en una respuesta inmediata de 3.7s. El agente le dice al usuario "trabajo iniciado" y puede verificar el estado más tarde, sin UI congelada y sin errores de timeout.

¿Por Qué Strands Agents para Integración MCP?

El MCPClient se conecta a cualquier servidor MCP en dos líneas. El agente descubre herramientas disponibles en tiempo de ejecución a través de list_tools_sync(), así que no mantienes una lista de herramientas codificada. Cuando el servidor MCP implementa el patrón handleId asíncrono, el agente consulta automáticamente sin código de orquestación adicional.

Strands soporta múltiples proveedores de modelos (OpenAI, Amazon Bedrock, Anthropic, Ollama). Los patrones de timeout de MCP mostrados aquí funcionan idénticamente en todos los proveedores.

Cuándo Usar Cada Patrón

Llamada directa (herramientas rápidas < 5s):

Búsquedas, cálculos, llamadas pequeñas a API
Sin riesgo de timeout

HandleId asíncrono (herramientas lentas > 5s):

Llamadas a API externas con latencia impredecible
Procesamiento de datos, generación de reportes
Cualquier operación que pueda exceder el timeout de MCP

Reintento con backoff (fallos intermitentes):

Servicios que ocasionalmente fallan pero se recuperan
Operaciones dependientes de red

Pruébalo Tú Mismo

Necesitas Python 3.9+, uv, y una clave API de OpenAI. El servidor MCP se ejecuta localmente como un subproceso, así que no se necesitan servicios externos.

git clone https://github.com/aws-samples/sample-why-agents-fail
cd sample-why-agents-fail/stop-ai-agents-wasting-tokens/02-mcp-timeout-demo
uv venv && uv pip install -r requirements.txt
export OPENAI_API_KEY="tu-clave-aquí"

uv run python test_mcp_timeout.py   # Ejecuta los 4 escenarios

O abre test_mcp_timeout.ipynb en Jupyter, JupyterLab, VS Code, o tu entorno de notebook preferido.

Conclusiones Clave

Las herramientas MCP hacen timeout silenciosamente — errores 424 sin recuperación
Las APIs lentas congelan todo el agente — espera de 17.8s sin retroalimentación
El patrón handleId asíncrono lo soluciona — respuesta inmediata, consultar por resultados
Diseña para el fallo — cada llamada externa puede hacer timeout, planifica en consecuencia

Preguntas Frecuentes

¿Qué causa errores 424 en llamadas a herramientas MCP?

Un error 424 (Failed Dependency) ocurre cuando una herramienta MCP tarda más que el umbral de timeout implícito (típicamente 7-10 segundos) en responder. El protocolo MCP espera que las herramientas devuelvan resultados rápidamente. Cuando una API externa bloquea la herramienta más allá de este umbral, la conexión se cae y el agente recibe un error 424 en lugar de datos.

¿Cuándo debo usar el patrón handleId asíncrono en lugar de una llamada directa a herramienta MCP?

Usa el patrón handleId asíncrono para cualquier herramienta que llame a una API externa con latencia impredecible: procesamiento de datos, generación de reportes, llamadas a servicios de terceros, o cualquier operación que pueda exceder 5 segundos. Para búsquedas rápidas, cálculos y llamadas pequeñas a API por debajo de 5 segundos, las llamadas directas funcionan bien.

¿El patrón handleId asíncrono funciona con cualquier servidor MCP, no solo Strands?

Sí. El patrón handleId asíncrono es un patrón de diseño de servidor MCP, no una característica de framework. Cualquier agente compatible con MCP puede llamar herramientas start_long_job y check_job_status. El patrón funciona con OpenAI Agents, integraciones MCP de LangChain, y cualquier cliente que soporte el Protocolo de Contexto de Modelo.

Referencias

Investigación

Resilient AI Agents With MCP: Timeout And Retry Strategies — Octopus blog (observación comunitaria), May 2025
Call remote MCP server tool timed out, error 424 — OpenAI Community (foro comunitario)
Handling Timeouts with Long-Running MCP Connectors — OpenAI Community (foro comunitario), Dec 2025
Build Timeout-Proof MCP Tools — Arsturn (observación comunitaria)

Implementación

Strands MCP Tools — Connect any MCP server
Strands Model Providers — Swap to Amazon Bedrock, Anthropic, Ollama

Gracias!

🇻🇪🇨🇱 Dev.to Linkedin GitHub Twitter Instagram Youtube

Elizabeth Fuentes LFollow

I help developers build production-ready AI applications through hands-on tutorials and open-source projects.

Migrando zig-lambda-runtime de Zig 0.12 a 0.16 en AWS Lambda

olcortesb — Mon, 18 May 2026 09:39:16 +0000

No soy experto en Zig, pero como me he divertido en esta prueba de concepto! Si han leído alguna vez algún artículo saben que me interesa es probar cómo funciona Lambda en cualquier entorno posible, en esta oportunidad, con un lenguaje de bajo nivel como Zig dentro de AWS Lambda, aprovechando el runtime provided.al2023 y la arquitectura ARM64. Este artículo documenta la migración del fork zig-lambda-runtime que originalmente fue desarrollado por softprops de Zig 0.12 a 0.16.

Por qué Zig en Lambda

Por estos números...

Cold start promedio: ~11ms
Memoria en promedio: ~10MB
Duración promedio: 1-2ms

Zig compila a un binario estático sin dependencias externas. No necesitas capas, no necesitas Docker. Solo un binario llamado bootstrap dentro de un zip.

Aunque necesito hacer más pruebas y compararlo, por ejemplo, con Rust, que es un lenguaje con el mismo concepto de no recolector de basura y alta performance, la verdad que promete que puede ser interesante.

Cambios principales en la migración

Y mientras aprendo un poco de Zig aquí los cambios que he hecho, que puede haber más y mejores pero la intención era hacerlo funcionar!

build.zig.zon

En 0.12 el nombre del paquete era un string. En 0.16 es un enum literal y se requiere un fingerprint:

// 0.12
.name = "lambda",
.minimum_zig_version = "0.12.0",

// 0.16
.name = .lambda,
.minimum_zig_version = "0.16.0",
.fingerprint = 0xd39dff828a4fab32,

El fingerprint se obtiene omitiendo el campo y dejando que Zig te diga el valor correcto en el primer build.

build.zig

La API de build cambió. Antes se usaba createModule + modules.put, ahora es addModule directo. Los ejecutables usan root_module en vez de root_source_file:

// 0.16
const lambda_module = b.addModule("lambda", .{
    .root_source_file = b.path("src/lambda.zig"),
    .link_libc = true,
});

const exe = b.addExecutable(.{
    .name = "bootstrap",
    .root_module = b.createModule(.{
        .root_source_file = b.path(example.src),
        .target = target,
        .optimize = optimize,
    }),
});
exe.root_module.addImport("lambda", lambda_module);

HTTP Client

El cambio más grande. En 0.12 existía client.fetch() como método de conveniencia. En 0.16 el ciclo de vida del request es explícito para el polling de invocaciones, aunque fetch sigue disponible para requests simples como enviar respuestas:

// Polling de invocaciones (explícito)
var threaded: std.Io.Threaded = .init(alloc, .{});
const io = threaded.io();
var client: std.http.Client = .{ .allocator = alloc, .io = io };
defer client.deinit();

const uri = std.Uri.parse(next_url) catch return error.InvalidNextUri;
var req = try client.request(.GET, uri, .{});
defer req.deinit();
try req.sendBodiless();

var header_buf: [8 * 1024]u8 = undefined;
var response = try req.receiveHead(&header_buf);
var reader = response.reader(&.{});
const body = try reader.allocRemaining(alloc, .unlimited);

// Enviar respuesta (fetch sigue funcionando)
_ = try client.fetch(.{
    .location = .{ .url = url },
    .method = .POST,
    .payload = payload,
});

GeneralPurposeAllocator

Cambio menor en la sintaxis de inicialización:

// 0.12
var gpa = std.heap.GeneralPurposeAllocator(.{}){};

// 0.16
var gpa: std.heap.GeneralPurposeAllocator(.{}) = .{};

Env y manejo de errores

Se reemplazó el .? (que hace panic si es null) por orelse para manejo graceful:

// 0.12 - panic si no existe
const runtime_api = std.posix.getenv("AWS_LAMBDA_RUNTIME_API").?;

// 0.16 - retorna error
const runtime_api = getenv("AWS_LAMBDA_RUNTIME_API") orelse return error.MissingLambdaEnv;

Deploy

El deploy usa SAM con un template mínimo:

Resources:
  Function:
    Type: AWS::Serverless::Function
    Properties:
      Runtime: provided.al2023
      Architectures:
        - arm64
      MemorySize: 128
      CodeUri: "../lambda.zip"
      Handler: handler
      FunctionUrlConfig:
        AuthType: NONE

El flujo completo:

# Build para ARM64 Linux
zig build apigw-example -Dtarget=aarch64-linux --summary all

# Empaquetar
zip -jq lambda.zip zig-out/bin/bootstrap

# Deploy
cd infra && sam deploy

Bugs corregidos en la migración

remaining_time_ms llamaba deadline_ms como función cuando es un campo, y el orden de la resta estaba invertido.
Variables indefinidas en el parsing de headers, reemplazadas por tipos nullable.
Lectura del body del response usando reader().readAllAlloc() en vez del patrón manual con ArrayList.

Resultado

La Lambda despliega y responde correctamente. El binario compilado para ARM64 es pequeño y los tiempos de respuesta se mantienen en el rango de 1-2ms después de la migración.

curl -s $(aws lambda get-function-url-config \
  --function-name zig-demo \
  --region us-east-1 \
  --query 'FunctionUrl' \
  --output text)
 # {"message":"hello world"}

Ejecuté 100 invocaciones con un script de benchmark y estos son los reportes de CloudWatch:

REPORT RequestId: e6c0c71c-...  Duration: 1.64 ms   Billed Duration: 2 ms   Memory Size: 128 MB  Max Memory Used: 13 MB
REPORT RequestId: 85c863bf-...  Duration: 1.57 ms   Billed Duration: 2 ms   Memory Size: 128 MB  Max Memory Used: 13 MB
REPORT RequestId: 9819ece8-...  Duration: 1.54 ms   Billed Duration: 2 ms   Memory Size: 128 MB  Max Memory Used: 13 MB
REPORT RequestId: 074f600b-...  Duration: 1.63 ms   Billed Duration: 2 ms   Memory Size: 128 MB  Max Memory Used: 13 MB
REPORT RequestId: da687f87-...  Duration: 10.08 ms  Billed Duration: 11 ms  Memory Size: 128 MB  Max Memory Used: 13 MB
REPORT RequestId: c7575544-...  Duration: 1.49 ms   Billed Duration: 2 ms   Memory Size: 128 MB  Max Memory Used: 14 MB
REPORT RequestId: e02e5bb4-...  Duration: 12.16 ms  Billed Duration: 13 ms  Memory Size: 128 MB  Max Memory Used: 14 MB
REPORT RequestId: 158b7657-...  Duration: 1.39 ms   Billed Duration: 2 ms   Memory Size: 128 MB  Max Memory Used: 14 MB

Resumen promediando los 100 invocaciones:

Duration típica: ~1.5ms
Picos ocasionales: 10-12ms (cold starts o micro-pauses del runtime)
Memoria usada: 13-14 MB de 128 MB asignados
Billed duration: 2ms en la mayoría de invocaciones

Posiblemente Zig no es un lenguaje que se esté usando masivamente, pero como ejercicio para entender cómo funciona un custom runtime en Lambda y qué tan lejos se puede llegar en performance, es interesante. La migración de 0.12 a 0.16 no fue trivial por los cambios en la stdlib (especialmente el HTTP client), pero el compilador te guía bastante bien con los errores.

Referencias

Cómo Evaluar AI Agents: Comparación de 3 Frameworks

Elizabeth Fuentes L — Mon, 18 May 2026 07:00:00 +0000

Al evaluar AI agents, la elección del framework determina tus puntajes. Ejecuta pruebas idénticas en Strands, PydanticAI y DeepEval y los números divergen hasta 40%. Esto no es un bug. Es por diseño.

La mayoría de las comparaciones de frameworks prueban diferentes agents con diferentes rúbricas y lo llaman justo. Esta ejecuta los mismos casos de prueba, mismo modelo de evaluación (Claude Sonnet 4 en Amazon Bedrock), mismos criterios de evaluación en los tres frameworks. La única variable es la API del framework.

La divergencia revela arquitectura. Strands y PydanticAI envían rúbricas directamente al modelo de evaluación para puntuación transparente. DeepEval usa G-Eval, una técnica respaldada por investigación que descompone la evaluación en pasos chain-of-thought y pondera puntajes con probabilidades de tokens. Diferentes metodologías, diferentes resultados, ambos válidos.

Lo que aprenderás:

Por qué los puntajes de GEval difieren del prompting directo de rúbricas (es por diseño, no un bug)
Qué framework funciona mejor para tu stack (AWS vs type-safety vs framework-agnostic)
Cuándo usar verificaciones determinísticas vs evaluación basada en LLM
Por qué PydanticAI no puede evaluar listas de herramientas pre-computadas (requisito de OpenTelemetry)

Lo que realmente se está comparando:

Strands Agents = Framework de agents + biblioteca de evaluación (strands-agents-evals), soporta 12+ proveedores de modelos
PydanticAI = Framework de agents + biblioteca de evaluación (pydantic-evals), soporta múltiples proveedores via Logfire
DeepEval = Framework solo de evaluación (funciona con cualquier agent)

DeepEval no construye agents. Solo los evalúa. Esto lo hace comparable a strands-agents-evals y pydantic-evals (las bibliotecas de evaluación), no a los frameworks completos Strands/PydanticAI.

El panorama de evaluación para AI agents vio más de 45 nuevos papers de investigación en los últimos 6 meses en arXiv (repositorio de preprints de acceso abierto de Cornell University), proponiendo nuevas métricas para calidad de trajectory (TRACE), detección de hallucinations (LSC), y compromisos costo-rendimiento (KAMI). Pero cuando se trata de implementar estas evaluaciones, ¿qué framework deberías usar?

¿Por qué estos 3 frameworks (y no CrewAI, LangGraph o AutoGen)?

Comparé 8 frameworks de agents por sus capacidades de evaluación. Los frameworks más populares (CrewAI, LangGraph, AutoGen, OpenAI Agents SDK, Google ADK) se enfocan en construir agents, no en evaluarlos. No incluyen bibliotecas dedicadas de evaluación.

Estos 3 fueron seleccionados porque son los únicos con SDKs de evaluación dedicados y de código abierto:

Framework	Biblioteca de Evaluación	Qué Proporciona
Strands Agents	`strands-agents-evals`	OutputEvaluator, TrajectoryEvaluator, ToolCalled, ActorSimulator, Experiment runner
PydanticAI	`pydantic-evals`	LLMJudge, Datasets tipados con YAML, diffing de reportes, HasMatchingSpan
DeepEval	`deepeval` (standalone)	30+ métricas: GEval, HallucinationMetric, FaithfulnessMetric, ToolCorrectnessMetric

¿Qué pasa con los demás?

Framework	Por Qué No Está Incluido
CrewAI	`crewai test` solo soporta OpenAI, proporciona puntuación básica de 1-10. Sin rúbricas, sin evaluación de trajectory, sin detección de hallucinations.
LangGraph	La evaluación vive en LangSmith (SaaS de pago), no en el framework de código abierto.
AutoGen	Tiene AutoGen Bench para benchmarking pero no un SDK de evaluación con métricas comparables.
OpenAI Agents SDK	Proporciona hooks de tracing pero no una biblioteca de evaluación. Combínalo con DeepEval para evaluar.
Google ADK	Tiene CLI `adk eval` pero está fuertemente acoplado al ecosistema Gemini.

Si usas CrewAI, LangGraph o AutoGen para construir tu agent, aún necesitas uno de estos 3 frameworks para evaluarlo. DeepEval en particular es framework-agnostic y funciona con cualquier agent.

¿Qué tareas de evaluación estamos ejecutando?

Evaluamos el mismo escenario de agente asistente de viajes en los tres frameworks. El agent responde preguntas de viajeros usando herramientas (buscar vuelos, verificar disponibilidad de hoteles, obtener clima).

Calidad de Salida - ¿La respuesta del agent es útil y precisa? (LLM-as-Judge)
Corrección de Herramientas - ¿El agent llamó las herramientas correctas con los parámetros correctos?
Detección de Hallucinations - ¿El agent fabricó información que no está en el contexto?
Faithfulness - ¿La respuesta está fundamentada en la información recuperada?

Mismos casos de prueba. Mismo modelo de evaluación (Claude en Amazon Bedrock). Mismas rúbricas donde sea posible.

Ronda 1: Calidad de Salida (LLM-as-Judge)

Respuesta rápida: Los tres frameworks soportan LLM-as-Judge con rúbricas personalizadas, pero Strands requiere menos líneas (7), PydanticAI ofrece las opciones de configuración más completas (modos de puntuación + aserción), y DeepEval soporta la gama más amplia de criterios personalizados via GEval. Strands y PydanticAI soportan Bedrock nativamente; DeepEval requiere un wrapper personalizado.

LLM-as-Judge es la técnica de evaluación más fundamental: usar un modelo de lenguaje grande para puntuar si la salida del agent cumple criterios de calidad. Los tres frameworks soportan este patrón, pero la API difiere significativamente.

Strands Agents (7 líneas)

Strands usa OutputEvaluator con una rúbrica personalizada, haciéndolo la opción más concisa para LLM-as-Judge básico:

from strands_evals import Experiment, Case
from strands_evals.evaluators import OutputEvaluator

cases = [
    Case(input="Find flights from NYC to London for next Friday",
         expected_output="Should include airline, price range, and departure times"),
]

evaluator = OutputEvaluator(
    rubric="Rate the response on helpfulness (0-1). A helpful response includes "
           "specific flight options with airlines, prices, and times. Penalize "
           "vague or generic responses.",
    model="us.anthropic.claude-sonnet-4-20250514-v1:0",
)

experiment = Experiment(cases=cases, evaluators=[evaluator])
reports = experiment.run_evaluations(lambda case: agent(case.input))
reports[0].display()

PydanticAI (10 líneas)

PydanticAI envuelve casos en un Dataset y proporciona modos de puntuación y aserción separados, dándote más control sobre criterios de aprobación/fallo:

from pydantic_evals import Case, Dataset
from pydantic_evals.evaluators import LLMJudge

dataset = Dataset(
    cases=[
        Case(
            name="flight_search",
            inputs="Find flights from NYC to London for next Friday",
            expected_output="Should include airline, price range, and departure times",
        ),
    ],
    evaluators=[
        LLMJudge(
            rubric="Rate the response on helpfulness. A helpful response includes "
                   "specific flight options with airlines, prices, and times. "
                   "Penalize vague or generic responses.",
            model="anthropic:claude-sonnet-4-6",
            include_input=True,
            include_expected_output=True,
            score={"include_reason": True},
        ),
    ],
)

report = dataset.evaluate_sync(lambda inputs: agent(inputs))
report.print(include_input=True)

DeepEval (12 líneas)

DeepEval usa GEval con parámetros de evaluación explícitos, permitiéndote controlar qué campos ve el evaluador:

from deepeval import evaluate
from deepeval.metrics import GEval
from deepeval.test_case import LLMTestCase, LLMTestCaseParams

test_case = LLMTestCase(
    input="Find flights from NYC to London for next Friday",
    actual_output=agent("Find flights from NYC to London for next Friday"),
    expected_output="Should include airline, price range, and departure times",
)

metric = GEval(
    name="Helpfulness",
    criteria="Rate the response on helpfulness. A helpful response includes "
             "specific flight options with airlines, prices, and times. "
             "Penalize vague or generic responses.",
    evaluation_params=[
        LLMTestCaseParams.INPUT,
        LLMTestCaseParams.ACTUAL_OUTPUT,
        LLMTestCaseParams.EXPECTED_OUTPUT,
    ],
    threshold=0.5,
)

result = evaluate(test_cases=[test_case], metrics=[metric])

Veredicto: ¿Qué Framework Gana?

Aspecto	Strands	PydanticAI	DeepEval
Líneas de código	7	10	12
Bedrock nativo	Sí	Sí	Necesita wrapper personalizado
Formato de puntuación	0.0-1.0	0.0-1.0 + pass/fail	0.0-1.0
Razón incluida	Sí	Sí (configurable)	Sí
Evaluación por lotes	`Experiment.run_evaluations()`	`Dataset.evaluate_sync()`	`evaluate()`
Método de prompting	Rúbrica directa → LLM	Rúbrica directa → LLM	G-Eval (CoT + logprobs)

Strands es el más conciso. PydanticAI ofrece la mayor configuración (modos separados de puntuación vs aserción). DeepEval usa GEval, una técnica respaldada por investigación del paper "G-Eval: NLG Evaluation using GPT-4 with Better Human Alignment".

⚠️ Por qué los puntajes pueden diferir: Incluso con el mismo modelo y texto de rúbrica, GEval usa una estrategia de prompting fundamentalmente diferente:

Descomposición chain-of-thought - Desglosa la evaluación en pasos explícitos
Ponderación de logprobs - Usa probabilidades de tokens para ponderar puntajes
Template estructurado - Formato de prompt optimizado para alineación humana

Esto es por diseño. GEval optimiza para correlación con juicios humanos, no para puntuación idéntica al prompting directo de rúbricas. Strands y PydanticAI optimizan para transparencia y personalizabilidad.

Ronda 2: Evaluación de Corrección de Herramientas

Respuesta rápida: Strands proporciona extracción de trajectory integrada y verificaciones determinísticas de herramientas (costo cero). DeepEval tiene un ToolCorrectnessMetric dedicado con comparación basada en LLM. El HasMatchingSpan de PydanticAI requiere instrumentación OpenTelemetry y no es comparable a los otros dos para validación simple de lista de herramientas.

La corrección de herramientas mide si el agent llamó las herramientas correctas con los parámetros correctos. Esto es crítico para agents que interactúan con APIs y bases de datos, porque una llamada incorrecta a una herramienta puede causar efectos secundarios en el mundo real.

⚠️ PydanticAI excluido de comparación directa: El evaluador HasMatchingSpan de PydanticAI requiere traces completos de OpenTelemetry de ejecución de agent en vivo. No puede evaluar listas de herramientas pre-computadas como ["search_flights", "check_availability"], haciéndolo fundamentalmente incomparable a ToolCalled de Strands y ToolCorrectnessMetric de DeepEval para validación básica de herramientas.

Strands Agents (con extracción de trajectory)

Strands automáticamente extrae el uso de herramientas de traces de ejecución del agent, haciendo la evaluación de trajectory fluida:

from strands_evals import Experiment, Case
from strands_evals.evaluators import TrajectoryEvaluator
from strands_evals.extractors import tools_use_extractor

traj_eval = TrajectoryEvaluator(
    rubric="The agent should search for flights first, then check availability. "
           "Calling weather tools is optional but acceptable.",
    model="us.anthropic.claude-sonnet-4-20250514-v1:0",
)

cases = [
    Case(
        input="Find flights from NYC to London for next Friday",
        expected_trajectory=["search_flights", "check_availability"],
    ),
]

def task_with_trajectory(case):
    agent.messages = []
    response = agent(case.input)
    traj_eval.update_trajectory_description(
        tools_use_extractor.extract_tools_description(agent)
    )
    trajectory = tools_use_extractor.extract_agent_tools_used_from_messages(
        agent.messages
    )
    return {"output": str(response), "trajectory": trajectory}

experiment = Experiment(cases=cases, evaluators=[traj_eval])
reports = experiment.run_evaluations(task_with_trajectory)

Bonus: Verificación determinística de herramientas (sin LLM necesario, costo cero)

Para verificaciones simples de "¿se llamó esta herramienta?", Strands proporciona verificación instantánea sin llamadas API:

from strands_evals.evaluators import ToolCalled

# Check if a specific tool was called (instant, no API call)
experiment = Experiment(
    cases=cases,
    evaluators=[ToolCalled(tool_name="search_flights")],
)

PydanticAI (con detección de herramientas basada en spans)

PydanticAI usa spans de OpenTelemetry para detectar uso de herramientas, requiriendo código de evaluador personalizado para validación de trajectory:

from dataclasses import dataclass
from pydantic_evals import Case, Dataset
from pydantic_evals.evaluators import Evaluator, EvaluatorContext, HasMatchingSpan

dataset = Dataset(
    cases=[
        Case(
            name="flight_search",
            inputs="Find flights from NYC to London for next Friday",
            metadata={"expected_tools": ["search_flights", "check_availability"]},
        ),
    ],
    evaluators=[
        HasMatchingSpan(
            query={"name_contains": "search_flights"},
            evaluation_name="called_search_flights",
        ),
    ],
)

# Custom evaluator for full trajectory check
@dataclass
class ToolSequenceCheck(Evaluator):
    def evaluate(self, ctx: EvaluatorContext) -> dict[str, bool]:
        tool_spans = ctx.span_tree.find(lambda n: "tool" in n.name.lower())
        tool_names = [s.name for s in tool_spans]
        expected = ctx.metadata.get("expected_tools", [])
        return {
            "all_tools_called": all(t in tool_names for t in expected),
            "correct_order": self._check_order(tool_names, expected),
        }

    def _check_order(self, actual, expected):
        positions = []
        for tool in expected:
            if tool in actual:
                positions.append(actual.index(tool))
        return positions == sorted(positions)

DeepEval (con objetos ToolCall)

DeepEval usa objetos estructurados ToolCall con validación explícita de parámetros y verificaciones de orden:

from deepeval import evaluate
from deepeval.metrics import ToolCorrectnessMetric
from deepeval.test_case import LLMTestCase, ToolCall

test_case = LLMTestCase(
    input="Find flights from NYC to London for next Friday",
    actual_output="I found 3 flights...",
    tools_called=[
        ToolCall(name="search_flights", input_parameters={"origin": "NYC", "dest": "LHR"}),
        ToolCall(name="check_availability", input_parameters={"flight_id": "BA117"}),
    ],
    expected_tools=[
        ToolCall(name="search_flights", input_parameters={"origin": "NYC", "dest": "LHR"}),
        ToolCall(name="check_availability"),
    ],
)

metric = ToolCorrectnessMetric(
    threshold=0.5,
    should_consider_ordering=True,
    should_exact_match=False,
)

result = evaluate(test_cases=[test_case], metrics=[metric])

Veredicto: ¿Qué Framework Gana?

Aspecto	Strands	PydanticAI	DeepEval
Extracción de trajectory	Extractor integrado	Via spans OpenTelemetry	Objetos ToolCall manuales
Eval de trajectory basada en LLM	TrajectoryEvaluator	No comparable (solo OTEL)	ToolCorrectnessMetric
Verificación determinística	ToolCalled (costo cero)	HasMatchingSpan (solo OTEL)	N/A
Validación de orden	in_order_match_scorer	Código personalizado	should_consider_ordering
Validación de parámetros	Via rúbrica	Via atributos de span	should_exact_match
Funciona con listas de herramientas pre-computadas	Sí	No (requiere traces en vivo)	Sí

Strands gana por simplicidad con extracción de trajectory integrada de mensajes del agent. DeepEval tiene la API de ToolCall más estructurada con comparación dedicada basada en LLM. PydanticAI es el más flexible via árboles de spans pero requiere instrumentación OpenTelemetry, haciéndolo adecuado solo para evaluación de agent en vivo, no análisis pre-computado.

Ronda 3: Detección de Hallucinations

Respuesta rápida: DeepEval proporciona un HallucinationMetric construido específicamente que descompone afirmaciones y verifica cada una contra el contexto. Strands y PydanticAI usan LLM-as-judge de propósito general con rúbricas personalizadas, lo cual es flexible pero menos especializado. DeepEval gana para detección de hallucinations con su métrica dedicada y conteo de contradicciones por contexto.

La detección de hallucinations mide si el agent fabrica información no presente en el contexto fuente. Esta es una de las dimensiones de evaluación más críticas, con investigación reciente (LSC, enero 2026) mostrando que métodos de detección zero-shot pueden identificar contenido fabricado sin datos de entrenamiento.

Strands Agents

Strands usa OutputEvaluator con una rúbrica enfocada en hallucinations:

from strands_evals import Experiment, Case
from strands_evals.evaluators import OutputEvaluator

cases = [
    Case(
        input="What is the baggage policy for Delta flights to London?",
        expected_output="Based on the context: 2 checked bags, 23kg each, free for international",
    ),
]

hallucination_eval = OutputEvaluator(
    rubric="Score 1.0 if the response ONLY contains information present in the "
           "expected output (ground truth). Score 0.0 if the response includes "
           "any fabricated details such as specific prices, dates, or policies "
           "not mentioned in the ground truth. Partially correct responses "
           "should score between 0.3-0.7.",
    model="us.anthropic.claude-sonnet-4-20250514-v1:0",
)

experiment = Experiment(cases=cases, evaluators=[hallucination_eval])
reports = experiment.run_evaluations(lambda case: agent(case.input))

PydanticAI

PydanticAI usa LLMJudge con modos de puntuación y aserción separados para detección de hallucinations:

from pydantic_evals import Case, Dataset
from pydantic_evals.evaluators import LLMJudge

dataset = Dataset(
    cases=[
        Case(
            name="baggage_policy",
            inputs="What is the baggage policy for Delta flights to London?",
            expected_output="Based on the context: 2 checked bags, 23kg each, free for international",
        ),
    ],
    evaluators=[
        LLMJudge(
            rubric="Does the response ONLY contain information present in the "
                   "expected output? Score 0.0 for fabricated details, 1.0 for "
                   "fully grounded responses.",
            model="anthropic:claude-sonnet-4-6",
            include_expected_output=True,
            score={"include_reason": True, "evaluation_name": "hallucination"},
            assertion={"include_reason": True, "evaluation_name": "grounded"},
        ),
    ],
)

report = dataset.evaluate_sync(lambda inputs: agent(inputs))

DeepEval (HallucinationMetric dedicado)

DeepEval proporciona un HallucinationMetric especializado que descompone respuestas en afirmaciones y verifica cada una contra el contexto fuente:

from deepeval import evaluate
from deepeval.metrics import HallucinationMetric
from deepeval.test_case import LLMTestCase

test_case = LLMTestCase(
    input="What is the baggage policy for Delta flights to London?",
    actual_output=agent("What is the baggage policy for Delta flights to London?"),
    context=[
        "Delta international flights include 2 checked bags at 23kg each, free of charge.",
        "Carry-on must fit in overhead bin. One personal item allowed.",
    ],
)

metric = HallucinationMetric(threshold=0.5)
result = evaluate(test_cases=[test_case], metrics=[metric])

Veredicto: ¿Qué Framework Gana?

Aspecto	Strands	PydanticAI	DeepEval
Métrica dedicada	No (via rúbrica OutputEvaluator)	No (via rúbrica LLMJudge)	Sí (HallucinationMetric)
Contexto como input	Via expected_output	Via expected_output	Campo de contexto dedicado
Método de puntuación	LLM judge con rúbrica	LLM judge con rúbrica	Verificación afirmación por afirmación
Granularidad	Puntuación única	Puntuación + aserción	Conteo de contradicciones por contexto

DeepEval gana aquí con un HallucinationMetric construido específicamente que descompone afirmaciones y verifica cada una contra el contexto. Strands y PydanticAI usan LLM-as-judge de propósito general con rúbricas personalizadas. Este enfoque es flexible pero menos especializado para detección de hallucinations.

Ronda 4: Evaluación por Lotes

Respuesta rápida: PydanticAI tiene el mejor reporte con diffing de baseline (comparar v1 vs v2). DeepEval tiene la mayor cantidad de métricas disponibles (30+). Strands tiene la API más limpia para mezclar evaluadores LLM y determinísticos en un solo experimento.

La evaluación del mundo real ejecuta múltiples métricas en múltiples casos de prueba al mismo tiempo. Esta sección compara cómo cada framework maneja ejecución paralela, tipos de métricas mixtas, y reporte.

Strands Agents

Strands combina múltiples evaluadores en un solo Experiment, ejecutando automáticamente todas las combinaciones:

from strands_evals import Experiment, Case
from strands_evals.evaluators import (
    OutputEvaluator, TrajectoryEvaluator, ToolCalled,
)

cases = [
    Case(input="Find flights NYC to London",
         expected_output="Flight options with prices",
         expected_trajectory=["search_flights"]),
    Case(input="What's the weather in Paris tomorrow?",
         expected_output="Temperature and conditions",
         expected_trajectory=["get_weather"]),
    Case(input="Book hotel in Tokyo for 3 nights",
         expected_output="Booking confirmation with dates and price",
         expected_trajectory=["search_hotels", "book_hotel"]),
]

experiment = Experiment(
    cases=cases,
    evaluators=[
        OutputEvaluator(rubric="Is the response helpful and specific?"),
        TrajectoryEvaluator(rubric="Did the agent use the right tools?"),
        ToolCalled(tool_name="search_flights"),
    ],
)

reports = experiment.run_evaluations(task_function)
for report in reports:
    report.display()

PydanticAI

PydanticAI usa Dataset.evaluate_sync() con un parámetro max_concurrency para ejecución paralela:

from pydantic_evals import Case, Dataset
from pydantic_evals.evaluators import LLMJudge, EqualsExpected, HasMatchingSpan

dataset = Dataset(
    cases=[
        Case(name="flights", inputs="Find flights NYC to London",
             expected_output="Flight options with prices"),
        Case(name="weather", inputs="What's the weather in Paris tomorrow?",
             expected_output="Temperature and conditions"),
        Case(name="hotel", inputs="Book hotel in Tokyo for 3 nights",
             expected_output="Booking confirmation with dates and price"),
    ],
    evaluators=[
        LLMJudge(rubric="Is the response helpful and specific?",
                 score={"include_reason": True}),
    ],
)

report = dataset.evaluate_sync(task_function, max_concurrency=3)
report.print(include_input=True, include_averages=True)

DeepEval

DeepEval usa AsyncConfig para controlar ejecución paralela y soporta el rango más amplio de métricas integradas:

from deepeval import evaluate
from deepeval.metrics import (
    GEval, AnswerRelevancyMetric, HallucinationMetric, ToolCorrectnessMetric,
)
from deepeval.test_case import LLMTestCase, LLMTestCaseParams
from deepeval.evaluate.configs import AsyncConfig

test_cases = [build_test_case(q) for q in questions]

metrics = [
    GEval(name="Helpfulness",
          criteria="Is the response helpful and specific?",
          evaluation_params=[LLMTestCaseParams.INPUT, LLMTestCaseParams.ACTUAL_OUTPUT]),
    AnswerRelevancyMetric(threshold=0.7),
    HallucinationMetric(threshold=0.5),
]

result = evaluate(
    test_cases=test_cases,
    metrics=metrics,
    async_config=AsyncConfig(max_concurrent=5),
)

Veredicto: ¿Qué Framework Gana?

Aspecto	Strands	PydanticAI	DeepEval
Ejecución paralela	`run_evaluations_async()`	parámetro `max_concurrency`	`AsyncConfig(max_concurrent=N)`
Tipos de métricas mixtas	LLM + determinístico	LLM + determinístico + span	Solo LLM (30+ métricas)
Formato de reporte	Tabla Rich via `.display()`	Tabla Rich via `.print()`	Consola + dashboard Confident AI
Diffing de reportes	No	Sí (parámetro `baseline=`)	Via Confident AI
Exportar	Archivo JSON	Archivo YAML/JSON	JSON/CSV + cloud

PydanticAI tiene el mejor reporte con diffing de baseline (comparar v1 vs v2). DeepEval tiene las métricas más disponibles. Strands tiene la API más limpia para mezclar evaluadores LLM y determinísticos.

¿Cuál es la comparación completa de características?

Esta tabla resume cada capacidad de evaluación en los tres frameworks. Úsala como referencia al elegir un framework para tus necesidades específicas de evaluación.

Característica	Strands + evals	PydanticAI + evals	DeepEval
LLM-as-Judge	OutputEvaluator	LLMJudge	GEval
Evaluación de trajectory	TrajectoryEvaluator + extractors	SpanTree + custom	ToolCorrectnessMetric
Detección de hallucinations	Via rúbrica	Via rúbrica	HallucinationMetric
Faithfulness	FaithfulnessEvaluator (trace)	Via rúbrica	FaithfulnessMetric
Verificaciones determinísticas	Equals, Contains, ToolCalled	Equals, Contains, IsInstance	N/A
Evaluación multi-agent	InteractionsEvaluator	Evaluador personalizado	N/A
Simulación multi-turn	ActorSimulator	N/A	ConversationalTestCase
Generación de casos de prueba	ExperimentGenerator	N/A	`deepeval generate`
Bedrock nativo	Sí	Sí	Wrapper personalizado
OpenTelemetry	Integrado	Via Logfire	N/A
Serialización de dataset	JSON	YAML/JSON	JSON/CSV
Comparación de reportes	No	Diffing de baseline	Confident AI
Integración con pytest	Via Experiment	`dataset.evaluate_sync()`	`assert_test()` / `deepeval test`
Total de métricas integradas	12 evaluadores	6 evaluadores + custom	30+ métricas

Pruébalo tú mismo

El notebook acompañante ejecuta todas las comparaciones con código en vivo. Puedes reproducir cada resultado de este artículo.

Un notebook Jupyter acompañante con ejemplos de código ejecutables está disponible en el repositorio de GitHub. El notebook incluye comparaciones lado a lado de los tres frameworks en las mismas tareas de evaluación.

Configuración

cd blog-framework-comparison
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

Preguntas frecuentes

¿Qué framework de evaluación de AI agents es más fácil de aprender?
Strands Agents requiere el menor número de líneas de código (7 líneas para LLM-as-Judge). PydanticAI está cerca con 10 líneas. DeepEval requiere la mayor configuración, especialmente para modelos que no son OpenAI donde necesitas una clase wrapper personalizada.

¿Strands, PydanticAI y DeepEval soportan Amazon Bedrock?
Strands y PydanticAI soportan Bedrock nativamente (configuración de una línea). DeepEval requiere un wrapper personalizado DeepEvalBaseLLM que mapea la API de Bedrock a la interfaz de DeepEval. El wrapper agrega aproximadamente 25 líneas de código.

¿Necesito OpenTelemetry para evaluar AI agents?
Solo para evaluadores basados en trace en Strands (como FaithfulnessEvaluator y ToolSelectionAccuracyEvaluator). Los evaluadores basados en output en los tres frameworks funcionan sin OpenTelemetry. PydanticAI usa OpenTelemetry via Logfire para evaluación basada en spans.

¿Cuál es el costo de ejecutar evaluaciones de AI agents?
Cada evaluador basado en LLM hace llamadas API al modelo de evaluación, lo que incurre en costos de tokens. Strands proporciona evaluadores determinísticos (como ToolCalled, Equals, Contains) que se ejecutan instantáneamente con costo cero. DeepEval y PydanticAI también tienen opciones determinísticas (Equals, Contains, IsInstance).

¿Puedo usar múltiples frameworks de evaluación juntos?
Sí. Puedes usar las métricas especializadas de DeepEval (como HallucinationMetric) junto con Strands Agents para el runtime del agent y captura de trajectory. Los frameworks evalúan outputs, no agents directamente, así que el framework de agent y el framework de evaluación son elecciones independientes.

Conclusión

No hay un framework de evaluación "mejor" único. La elección correcta depende de tu stack, prioridades y qué estás comparando.

Punto clave: Diferentes metodologías producen diferentes puntajes por diseño.

Strands y PydanticAI envían rúbricas directamente al LLM (transparente, personalizable)
DeepEval usa técnicas respaldadas por investigación como G-Eval (optimizado para alineación humana)
PydanticAI requiere OpenTelemetry para evaluación de herramientas (solo traces en vivo)
Strands y DeepEval funcionan con datos pre-computados (pruebas más simples)

Cuándo usar cada uno:

Strands Agents es la opción más cohesiva si quieres un framework unificado para creación y evaluación de agents. Creación de agents, llamado de herramientas, captura de trajectory y evaluación viven en el mismo ecosistema. El sistema de hooks y métricas integradas significa que la evaluación está instrumentada en el runtime del agent, no agregada después del hecho. Mejor para equipos que quieren un framework completo de agents con evaluación integrada. Soporta 12+ proveedores de modelos incluyendo AWS Bedrock, OpenAI, Anthropic, Gemini, Ollama, y LiteLLM (para 100+ proveedores más).

PydanticAI es la opción más elegante si valoras type safety y pipelines de evaluación estructurados. Datasets YAML, diffing de reportes, y el protocolo Evaluator lo hacen ideal para equipos que quieren evaluación-como-código con garantías fuertes. Mejor para equipos priorizando type safety y pipelines reproducibles.

DeepEval es la opción más completa si quieres métricas especializadas sin construirlas tú mismo. Más de 30 métricas, incluyendo detección de hallucinations construida específicamente y verificación de faithfulness, te permiten evaluar inmediatamente sin escribir rúbricas personalizadas. Mejor para evaluación framework-agnostic con técnicas validadas por investigación.

Los conceptos de evaluación (LLM-as-judge, puntuación de trajectory, detección de hallucinations) son independientes del framework. Los papers de investigación y técnicas detrás de ellos funcionan independientemente de qué framework elijas. Para la lista completa de 45+ papers que informaron esta comparación, consulta el archivo RESEARCH.md.

Amazon Bedrock AgentCore: Una Cuarta Opción

Amazon Bedrock AgentCore proporciona evaluadores integrados y despliegue administrado para agents. Si estás comprometido con AWS y quieres una solución completamente administrada, AgentCore vale la pena considerar junto con los frameworks de código abierto.

Evaluadores Integrados

AgentCore incluye 13 evaluadores pre-construidos accesibles via el CLI de AgentCore y AWS SDK. Estos evaluadores cubren dimensiones comunes de evaluación sin requerir código personalizado:

Evaluador	Qué Mide	Cuándo Usar
`Builtin.Helpfulness`	Calidad y relevancia de output	Mismo caso de uso que Strands OutputEvaluator
`Builtin.GoalSuccessRate`	Precisión de completar tareas	Métrica binaria de éxito (comparar con puntuación de trajectory)
`Builtin.ToolSelection`	Corrección de elección de herramientas	Igual que Strands ToolCalled o DeepEval ToolCorrectnessMetric
`Builtin.Faithfulness`	Fundamentación en contexto recuperado	Igual que DeepEval FaithfulnessMetric
`Builtin.Harmfulness`	Cumplimiento de seguridad y política	Detecta outputs inseguros

Cómo funcionan las evaluaciones: Invocas el comando CLI agentcore run eval con tu ID de agent, el nombre del evaluador deseado (como Builtin.Helpfulness), y un archivo de casos de prueba. AgentCore ejecuta el agent en cada caso de prueba y devuelve un reporte JSON con puntajes y razonamiento para cada consulta. Consulta la Guía de Evaluación de AgentCore para ejemplos.

Captura de Trace para Observabilidad

AgentCore captura traces completos de ejecución cuando habilitas el parámetro enableTrace en la llamada API invoke_agent. Los traces incluyen:

Rationale: El razonamiento del agent antes de cada llamada de herramienta
Invocaciones de herramientas: Qué herramientas fueron llamadas con qué parámetros
Observaciones: Resultados devueltos de cada herramienta
Pasos de orquestación: La secuencia completa de toma de decisiones

Todos los traces se registran automáticamente en Amazon CloudWatch para análisis y monitoreo. Puedes consultar traces usando CloudWatch Logs Insights o exportarlos a S3 para análisis por lotes. Consulta la Documentación de Tracing de Bedrock Agent para detalles del esquema de trace.

Cuándo usar AgentCore:

Ya estás en AWS y quieres un servicio administrado
Necesitas observabilidad nativa de CloudWatch y logging de cumplimiento
Tu equipo prefiere infraestructura-como-código (CDK/CloudFormation) sobre scripts de evaluación personalizados
No necesitas evaluar agents en otros proveedores de cloud

Cuándo usar frameworks de código abierto:

Despliegue multi-cloud (Strands funciona con Bedrock, OpenAI, Anthropic, Ollama)
Necesitas control fino sobre lógica de evaluación
Quieres iterar rápidamente en métricas personalizadas sin desplegar funciones Lambda
Investigación o prototipado donde la flexibilidad importa más que infraestructura administrada

Recursos de AgentCore

Gracias!

🇻🇪🇨🇱 Dev.to Linkedin GitHub Twitter Instagram Youtube

Elizabeth Fuentes LFollow

I help developers build production-ready AI applications through hands-on tutorials and open-source projects.

Desbordamiento de Ventana de Contexto de IA: Solución con Puntero de Memoria

Elizabeth Fuentes L — Thu, 14 May 2026 07:00:00 +0000

El desbordamiento de ventana de contexto** ocurre cuando las salidas de herramientas de un agente de IA exceden el límite de tokens que el modelo de lenguaje grande (LLM) puede procesar de una vez. El agente no falla: silenciosamente trunca datos, pierde contexto anterior o produce resultados incompletos. Este post muestra cómo el Patrón de Puntero de Memoria lo soluciona: desde agente único hasta coordinación multi-agente donde 145KB de datos nunca entran en ningún contexto de LLM.

Esta demo usa Strands Agents. El Patrón de Puntero de Memoria es independiente del framework y se puede aplicar con LangGraph, AutoGen u otros frameworks de agentes que soporten contexto de herramientas.

Código funcional: github.com/aws-samples/sample-why-agents-fail

Serie: Por Qué Fallan los Agentes de IA

Desbordamiento de Ventana de Contexto (este post) — Patrón de Puntero de Memoria para datos grandes
Herramientas MCP Que Nunca Responden — Patrón asíncrono para APIs externas lentas
Loops de Razonamiento en Agentes de IA — Detectar y bloquear llamadas repetidas a herramientas

El Problema: Los Agentes No Pueden Manejar Salidas Grandes de Herramientas

Cuando un agente de IA llama a una herramienta que devuelve datos grandes (logs del servidor, resultados de bases de datos, contenidos de archivos), la respuesta puede desbordar la ventana de contexto del LLM. El agente no falla con un error claro. Se degrada silenciosamente: trunca datos, pierde contexto o no completa la tarea.

Una investigación de IBM (Solving Context Window Overflow in AI Agents, 2025) cuantifica esto:

En flujos de trabajo de Ciencia de Materiales, las salidas de herramientas pueden alcanzar más de 2 millones de elementos
El enfoque tradicional consumió 20,822,181 tokens y falló
El mismo flujo con punteros de memoria usó 1,234 tokens y tuvo éxito
Eso es una reducción de más de 16,000x en este flujo de trabajo

Una observación comunitaria (Context Window Limits Explained, Airbyte 2025) confirma que los equipos descubren estos límites "de la manera difícil" a través de errores silenciosos. El agente parece funcionar pero produce resultados incompletos o incorrectos.

El concepto de pasar referencias en lugar de datos sin procesar también ha sido validado en configuraciones multi-agente. Una investigación de Amazon (Towards Effective GenAI Multi-Agent Collaboration, 2024) introduce "referenciación de carga útil", donde los agentes intercambian punteros a datos compartidos en lugar de incrustar cargas grandes en mensajes. Esto mejoró el rendimiento en tareas intensivas en código en un 23% y logró tasas de éxito de objetivos de extremo a extremo del 90% en benchmarks empresariales. Esto es exactamente lo que implementamos a continuación con Strands Swarm.

Por Qué Sucede Esto

Cuando la salida de la herramienta es pequeña (unos pocos KB), esto funciona bien. Pero cuando una herramienta devuelve 200KB de logs del servidor:

La salida completa se inyecta en la conversación
La ventana de contexto del LLM se llena
El contexto más antiguo (incluida la pregunta original) se expulsa
El LLM no puede razonar sobre los datos porque no puede verlos todos
El agente falla o produce respuestas incompletas

Solución 1: Agente Único con Strands ToolContext

El primer enfoque usa agent.state, un almacén clave-valor nativo con alcance para cada instancia de agente. Las herramientas escriben datos grandes allí vía ToolContext y devuelven una cadena de puntero corta al contexto:

from strands import Agent, tool, ToolContext

# context=True inyecta ToolContext como el último parámetro — requerido para acceder a agent.state
@tool(context=True)
def fetch_application_logs(app_name: str, tool_context: ToolContext, hours: int = 24) -> str:
    """Obtiene logs de aplicación. Devuelve un puntero de memoria para datasets grandes."""
    logs = generate_logs(app_name, hours)  # Podría ser 200KB+

    if len(str(logs)) > 20_000:  # Umbral: almacenar externamente por encima de 20KB
        pointer = f"logs-{app_name}"
        # Almacena la carga útil completa en agent.state — nunca entra al contexto del LLM
        tool_context.agent.state.set(pointer, logs)
        # Devuelve solo la clave del puntero (52 bytes) — esto es todo lo que ve el LLM
        return f"Datos almacenados como puntero '{pointer}'. Usa herramientas de análisis para consultarlo."
    return str(logs)  # Suficientemente pequeño para devolver directamente

@tool(context=True)
def analyze_error_patterns(data_pointer: str, tool_context: ToolContext) -> str:
    """Analiza errores — resuelve puntero desde agent.state."""
    # Recupera el dataset completo desde agent.state usando la clave del puntero
    data = tool_context.agent.state.get(data_pointer)
    errors = [e for e in data if e["level"] == "ERROR"]
    # Devuelve un resumen (no datos sin procesar) — mantiene la respuesta pequeña
    return f"Se encontraron {len(errors)} errores en {len(set(e['service'] for e in errors))} servicios"

El LLM nunca ve los 200KB. Solo ve "Datos almacenados como puntero 'logs-payment-service'" (52 bytes). La siguiente herramienta lee los datos completos desde agent.state y devuelve un resumen. Strands proporciona esta capacidad nativamente, sin diccionarios globales, sin hashlib, sin infraestructura externa.

Resultados de Agente Único

Métrica	Sin Punteros	Con Punteros de Memoria
Datos en contexto	214KB (logs completos)	52 bytes (puntero)
Comportamiento del agente	Trunca/falla	Procesa todos los datos
Errores detectados	Parcial	Completo (todos los servicios)

Solución 2: Multi-Agente con Strands Swarm

Un solo agente funciona para pipelines lineales. Pero la respuesta a incidentes del mundo real involucra roles especializados: alguien obtiene datos, alguien los analiza, alguien escribe el reporte. Strands Swarm coordina múltiples agentes autónomamente: define agentes con diferentes herramientas, y el Swarm maneja los traspasos.

Este es el mismo patrón de "referenciación de carga útil" del paper de colaboración multi-agente de Amazon. Los agentes intercambian punteros a datos compartidos en lugar de pasar cargas sin procesar. La diferencia es que Strands Swarm maneja la coordinación automáticamente, y proporciona invocation_state como la API oficial para compartir datos entre agentes.

from strands import Agent, tool, ToolContext
from strands.multiagent import Swarm

# invocation_state es un dict compartido entre todos los agentes en el Swarm — el almacén entre agentes
@tool(context=True)
def fetch_application_logs(app_name: str, tool_context: ToolContext, hours: int = 6) -> str:
    logs = generate_logs(hours)  # 145KB+
    pointer = f"logs-{app_name}"
    # Almacena en invocation_state para que todos los agentes descendentes puedan acceder sin re-obtener
    tool_context.invocation_state[pointer] = logs
    # Solo la cadena de puntero viaja a través del contexto del LLM al siguiente agente
    return f"Almacenado como '{pointer}'. Traspasar a analyzer."

@tool(context=True)
def analyze_error_patterns(logs_pointer: str, tool_context: ToolContext) -> str:
    # Resuelve el puntero al dataset completo — sin contexto de LLM consumido
    logs = tool_context.invocation_state.get(logs_pointer)
    errors = [l for l in logs if l["level"] == "ERROR"]
    result = {"total_errors": len(errors)}  # campos adicionales omitidos por brevedad
    # Almacena resultados de análisis como otro puntero para el agente reporter
    tool_context.invocation_state["error_analysis"] = result
    return json.dumps(result)

# Cada agente tiene un rol enfocado; el Swarm decide el orden de traspaso autónomamente
collector = Agent(name="collector", tools=[fetch_application_logs], model=MODEL)
analyzer = Agent(name="analyzer", tools=[analyze_error_patterns, detect_latency_anomalies], model=MODEL)
reporter = Agent(name="reporter", tools=[generate_incident_report], model=MODEL)

swarm = Swarm([collector, analyzer, reporter], entry_point=collector)
result = swarm("Obtén logs, analiza y genera reporte de incidente.")

El Swarm automáticamente:

Comienza con el collector, que obtiene 145KB de logs y los almacena en invocation_state
El collector traspasa al analyzer con el puntero "logs-payment-service"
El analyzer ejecuta análisis de errores y latencia, almacena resultados en invocation_state, traspasa al reporter
El reporter genera el reporte de incidente final

No se necesita código de orquestación ni lógica de traspaso manual. Cada agente tiene sus propias herramientas y el Swarm determina el flujo a partir de las descripciones de agentes y la tarea. Todo el intercambio de datos ocurre vía tool_context.invocation_state, la misma API de ToolContext usada en agente único, con un almacén diferente.

Resultados de Swarm

Status: COMPLETED
Agents: collector → analyzer → reporter
Time: ~14s
Shared store:
  logs-payment-service: 145,310 bytes
  error_analysis: 135 bytes
  latency_analysis: 70 bytes

145KB de logs procesados por tres agentes. Nada de eso entró nunca a ninguna ventana de contexto de LLM.

Investigación de Seguimiento

Después de que el swarm se completa, los datos permanecen en el almacén compartido. Un agente investigador separado puede profundizar en servicios específicos sin re-obtener:

# El investigator reutiliza invocation_state poblado por el swarm — sin re-obtención de datos
investigator = Agent(
    name="investigator",
    tools=[get_error_details, analyze_error_patterns],
    model=MODEL,
)

# Cada pregunta resuelve el puntero desde invocation_state y ejecuta análisis en memoria
investigator("¿Qué servicio tuvo más errores?")
investigator("Muéstrame los logs de error de cache-layer")
investigator("¿Qué códigos de estado devuelven esos errores?")
# Todas las consultas leen de los mismos 145KB ya en invocation_state — sin re-obtención, sin desbordamiento de contexto

Cuándo Usar Cada Enfoque

Agente único + agent.state — pipelines lineales donde un agente maneja obtención + análisis + reporte. Usa ToolContext para acceder a tool_context.agent.state desde herramientas.

Swarm + invocation_state — roles especializados, flujos complejos, o cuando quieres coordinación autónoma. Usa ToolContext para acceder a tool_context.invocation_state: la API oficial de Strands para intercambio de datos multi-agente. El Swarm gestiona traspasos, timeouts y detección de traspasos repetitivos.

Ambos — usa SlidingWindowConversationManager como protección adicional. Recorta automáticamente el historial de conversación y maneja ContextWindowOverflowException con reintento.

Estos enfoques son parte de ingeniería de contexto para agentes de IA: la práctica de decidir qué información entra a la ventana de contexto del LLM y cuándo.

Pruébalo Tú Mismo

Necesitas Python 3.9+, uv, y una clave API de OpenAI.

git clone https://github.com/aws-samples/sample-why-agents-fail
cd sample-why-agents-fail/stop-ai-agents-wasting-tokens/01-context-overflow-demo
uv venv && uv pip install -r requirements.txt
export OPENAI_API_KEY="tu-clave-aquí"

uv run python test_context_overflow.py   # Agente único: 4 escenarios
uv run python swarm_demo.py              # Multi-agente: Collector → Analyzer → Reporter

O abre test_context_overflow.ipynb en Kiro, VS Code, o tu entorno de notebook preferido.

Conclusiones Clave

El desbordamiento de contexto es silencioso — los agentes no fallan, producen resultados incorrectos
Los punteros de memoria lo solucionan — almacena datos grandes externamente, pasa referencias
Reducción de >16,000x en tokens — validado por IBM Research en el benchmark de Ciencia de Materiales
Agente único usa agent.state — @tool(context=True) + ToolContext para almacenar y recuperar datos fuera del contexto
Multi-agente usa invocation_state — misma API de ToolContext, compartida entre todos los agentes en el Swarm. No se necesita código de orquestación
Los datos persisten para seguimiento — después de que el pipeline se completa, los datos almacenados están disponibles para investigación sin re-obtención

Preguntas Frecuentes

¿Por qué los agentes de IA se quedan sin contexto?

Los agentes de IA se quedan sin contexto cuando las respuestas de herramientas se inyectan directamente en el historial de conversación del LLM. Cada respuesta consume tokens. Cuando las salidas acumuladas de herramientas exceden el límite de ventana de contexto del modelo, el LLM pierde contexto anterior, trunca datos o falla por completo. Esto sucede silenciosamente: el agente parece funcionar pero produce resultados incompletos o incorrectos.

¿Qué es el Patrón de Puntero de Memoria para agentes de IA?

El Patrón de Puntero de Memoria almacena salidas grandes de herramientas (logs, datasets, resultados de consultas) en estado externo en lugar de en la ventana de contexto del LLM. Las herramientas devuelven una clave de referencia corta (el "puntero") que herramientas subsiguientes usan para recuperar los datos completos. IBM Research validó este patrón con una reducción de más de 16,000x en el benchmark de Ciencia de Materiales.

¿En qué se diferencia agent.state de invocation_state en Strands Agents?

agent.state tiene alcance para una sola instancia de agente. Úsalo para pipelines lineales donde un agente maneja todos los pasos. invocation_state se comparte entre todos los agentes en un Strands Swarm. Úsalo cuando múltiples agentes especializados necesitan intercambiar datos sin pasar cargas grandes a través del contexto del LLM.

¿Puedo usar el Patrón de Puntero de Memoria con LangGraph u otros frameworks?

Sí. El patrón requiere dos capacidades: un almacén clave-valor compartido accesible desde herramientas, y la capacidad de pasar cadenas de referencia cortas a través del contexto del LLM. LangGraph proporciona esto a través de su gestión de estado, AutoGen a través de memoria compartida, y CrewAI a través de contexto de tareas. La implementación de Strands usa ToolContext como la API nativa.

Referencias

Investigación

Solving Context Window Overflow in AI Agents — IBM Research, Nov 2025
Towards Effective GenAI Multi-Agent Collaboration — Amazon, Dec 2024
Context Window Limits Explained — Airbyte blog (observación comunitaria), Dec 2025
Efficient On-Device Agents via Adaptive Context Management — Nov 2025

Implementación

Strands Agent State — ToolContext and agent.state
Strands Swarm — Multi-agent orchestration
Strands Conversation Management — Sliding window and context overflow

¿Has alcanzado límites de ventana de contexto en tus agentes? ¿Qué estrategias funcionaron para ti? Comparte en los comentarios.

Siguiente en esta serie: Herramientas MCP Que Nunca Responden — patrones asíncronos para APIs externas lentas.

Todo el código en esta serie es open source bajo la Licencia MIT-0. Dale estrella al repositorio para seguir las actualizaciones.

Gracias!

🇻🇪Dev.to - Linkedin - GitHub - Twitter - Instagram - Youtube

Cómo Monitorear Costos de Agentes IA sin Configuración

Elizabeth Fuentes L — Wed, 13 May 2026 07:00:00 +0000

Strands Agents proporciona telemetría nativa y seguimiento de costos desde el primer momento. Deja de escribir contadores de tokens personalizados.

Construir agentes de IA es fácil. Desplegarlos a producción es donde la mayoría de los equipos se encuentran con un muro.

Una de las primeras preguntas de finanzas: "¿Cuánto costará esto por solicitud?"

La mayoría de los frameworks de agentes te obligan a construir tu propio contador de tokens. Strands Agents te proporciona uno.

El Problema con el Conteo Personalizado de Tokens

Cada aplicación de IA necesita monitoreo de costos. Pero rastrear tokens a través de:

Múltiples llamadas al modelo
Invocaciones de herramientas
Caché de prompts
Flujos de trabajo multi-agente

...requiere infraestructura personalizada que la mayoría de los equipos reconstruyen desde cero.

Telemetría Nativa en Strands Agents

Strands Agents incluye telemetría de grado de producción por defecto:

from strands import Agent
from strands_tools import calculator

# Crear un agente con herramientas
agent = Agent(tools=[calculator])

# Invocar el agente con un prompt y obtener un AgentResult
result = agent("¿Cuál es la raíz cuadrada de 144?")

# Acceder a métricas a través del AgentResult
print(f"Tokens totales: {result.metrics.accumulated_usage['totalTokens']}")
print(f"Tiempo de ejecución: {sum(result.metrics.cycle_durations):.2f} segundos")
print(f"Herramientas usadas: {list(result.metrics.tool_metrics.keys())}")

# Métricas de caché (cuando estén disponibles)
if 'cacheReadInputTokens' in result.metrics.accumulated_usage:
    print(f"Tokens leídos de caché: {result.metrics.accumulated_usage['cacheReadInputTokens']}")
if 'cacheWriteInputTokens' in result.metrics.accumulated_usage:
    print(f"Tokens escritos en caché: {result.metrics.accumulated_usage['cacheWriteInputTokens']}")

Sin configuración. Sin código personalizado. Simplemente funciona.

Lo Que Obtienes

Cada AgentResult incluye:

Métrica	Descripción
`inputTokens`	Tokens enviados al modelo
`outputTokens`	Tokens generados por el modelo
`totalTokens`	Costo total (entrada + salida)
`cacheReadInputTokens`	Tokens leídos desde caché (caché de prompts de Bedrock)
`cacheWriteInputTokens`	Tokens escritos en caché

Seguimiento de Tokens Multi-Agente

Para sistemas multi-agente (ejecutor → validador → crítico), agrega métricas a través de todos los agentes:

from strands.multiagent import Swarm

swarm = Swarm([executor, validator, critic])
result = swarm("Consulta")

total_tokens = 0
for node_result in result.results.values():
    usage = node_result.result.metrics.accumulated_usage
    total_tokens += usage['totalTokens']

print(f"Costo total a través de todos los agentes: {total_tokens} tokens")

Seguimiento por Ciclo

Para agentes que ejecutan múltiples ciclos de razonamiento, rastrea tokens por ciclo:

from strands import Agent
from strands_tools import calculator

agent = Agent(tools=[calculator])

# Primera invocación
result1 = agent("¿Cuánto es 5 + 3?")

# Segunda invocación
result2 = agent("¿Cuál es la raíz cuadrada de 144?")

# Acceder a métricas de la última invocación
latest_invocation = result2.metrics.latest_agent_invocation
cycles = latest_invocation.cycles
usage = latest_invocation.usage

# O acceder a todas las invocaciones
for invocation in response.metrics.agent_invocations:
    print(f"Uso de invocación: {invocation.usage}")
    for cycle in invocation.cycles:
        print(f"  Ciclo {cycle.event_loop_cycle_id}: {cycle.usage}")

# O imprimir el resumen (incluye todas las invocaciones)
print(result2.metrics.get_summary())

Para una lista completa de atributos y sus tipos, consulta la referencia de API de EventLoopMetrics.

Por Qué Esto Importa

La visibilidad de costos es la diferencia entre un prototipo y una IA en producción.

Con la telemetría de Strands:

✅ Presupuesta cargas de trabajo de IA antes del despliegue
✅ Identifica consultas costosas en producción
✅ Optimiza prompts con datos reales de tokens
✅ Rastrea ahorros del caché de prompts

Todo sin escribir una sola línea de código de telemetría.

Funciona con Todos los Proveedores de Modelos

El seguimiento de tokens funciona independientemente de tu proveedor de modelo:

Amazon Bedrock (Claude, Llama, Mistral)
OpenAI (GPT-4, GPT-3.5)
Anthropic API
Ollama (modelos locales)

Misma API, mismas métricas, cero cambios de configuración.

Pruébalo

pip install strands-agents

Documentación completa: strandsagents.com/docs/user-guide/concepts/agents/

Gracias!

🇻🇪🇨🇱 Dev.to Linkedin GitHub Twitter Instagram Youtube

Elizabeth Fuentes LFollow

I help developers build production-ready AI applications through hands-on tutorials and open-source projects.

Cómo Guiar Asistentes de IA para Construir Agentes Listos para Producción: 8 Patrones Esenciales

Elizabeth Fuentes L — Mon, 11 May 2026 18:54:52 +0000

Cuando le pides a un asistente de IA como Kiro (el asistente de IA de AWS), Claude Code o ChatGPT que "construya un agente," obtienes código funcional. Pero no ves las decisiones de arquitectura que ocurren detrás de escena. El agente responde a consultas, pero podría desperdiciar tokens en bucles de razonamiento, alucinar respuestas a partir de datos incompletos, o congelarse con APIs lentas. Estas fallas son silenciosas hasta llegar a producción.

Cuando le pides a asistentes de IA que construyan agentes, toman decisiones de arquitectura silenciosamente—eligiendo estrategias de recuperación, enfoques de validación y patrones de manejo de errores. Estos 8 patrones te dan el vocabulario para especificar decisiones de grado producción en tus prompts, previniendo alucinaciones y desperdicio de tokens antes de que se genere código.

Este post cierra dos series que escribí documentando las fallas de agentes más costosas en producción: Stop AI Agent Hallucinations (5 técnicas) y Why AI Agents Fail (3 modos de falla). Si conoces estos 8 patrones, puedes guiar a los asistentes de IA para evitarlos desde el inicio.

Esto no es una guía de implementación paso a paso. Es una referencia para saber qué existe y así reconocer cuándo usar cada patrón según tu caso de uso.

Código funcional para las 8 técnicas: Enlazado en cada sección

Por Qué Esto Importa

Los asistentes de IA generan código de agentes en segundos. Kiro, Claude Code, Cursor y ChatGPT pueden crear estructuras de herramientas, configurar llamadas a LLM y conectar sistemas de recuperación más rápido que programar manualmente.

Pero la velocidad crea un problema: obtienes código funcional sin ver las concesiones.

Cuando escribes "construye un agente de reservas con RAG," el asistente toma decisiones:

¿Qué estrategia de recuperación? (similitud vectorial, consultas de grafos, híbrido)
¿Cómo manejar salidas grandes? (truncar, resumir, almacenamiento externo)
¿Qué validación se ejecuta antes de usar una herramienta? (ninguna, prompts, hooks de framework)
¿Cómo manejar APIs lentas? (bloquear, timeout, patrones asíncronos)

Tu prompt no especifica esto. El asistente elige valores por defecto. Esos valores por defecto crean los modos de falla que este post documenta.

Los 8 Patrones de Falla (Referencia Rápida)

Fallas por Alucinación (5 patrones):

GraphRAG - RAG vectorial fabrica estadísticas a partir de fragmentos incompletos
Semantic Tool Selection - Demasiadas herramientas, el agente elige las equivocadas
Neurosymbolic Guardrails - El agente ignora reglas de negocio en los prompts
Runtime Guardrails (Steering) - El agente viola reglas, necesita corrección no bloqueo
Multi-Agent Validation - Un solo agente afirma éxito cuando las operaciones fallan

Desperdicio Silencioso de Tokens (3 patrones):

Memory Pointer Pattern - Datos grandes desbordan el contexto, causan truncamiento
Async HandleId Pattern - APIs lentas bloquean el agente indefinidamente
DebounceHook + Explicit States - El agente hace bucle con la misma llamada sin progreso

No implementas los 8. Aprendes qué resuelven, luego especificas los que tu caso de uso necesita al hacer prompts.

¿Qué Son Estos 8 Patrones?

Estos patrones resuelven las fallas de producción más costosas: alucinaciones por datos incompletos (GraphRAG, Semantic Tool Selection, Guardrails, Steering, Multi-Agent), y desperdicio silencioso de tokens (Memory Pointers, Async HandleId, DebounceHook). Aprendes qué resuelve cada uno, luego especificas los que tu caso de uso necesita al pedir a asistentes de IA. Esto previene depurar código de caja negra en producción.

Impacto Medido en Producción

Patrón	Resultado	Fuente
GraphRAG	Conteos exactos vs aproximaciones fabricadas	RAG vs GraphRAG
Semantic Tool Selection	86.4% menos errores, 89% menos costos de tokens	Tool Selection
Memory Pointers	20M tokens reducidos a 1,234 tokens	estudio IBM Materials Science
Async HandleId	Bloqueo de 18 segundos eliminado, sin timeouts 424	MCP Timeouts
Explicit States	14 llamadas reducidas a 2 (mejora de 7x)	Reasoning Loops

Patrón 1: GraphRAG para Consultas Precisas

¿Qué Es GraphRAG?

GraphRAG reemplaza la similitud vectorial con consultas a bases de datos de grafos para datos estructurados. Cuando tu agente necesita conteos exactos, agregaciones o recorrido de relaciones, GraphRAG traduce lenguaje natural a consultas Cypher que retornan resultados precisos desde datos estructurados en lugar de estadísticas alucinadas desde fragmentos de texto. Úsalo para consultas estructuradas, mantén RAG vectorial para búsqueda semántica.

Qué Se Rompe

RAG vectorial fabrica estadísticas. Preguntas "¿Cuántos hoteles en Miami tienen piscina y desayuno?" y la similitud vectorial recupera 3 fragmentos de texto que mencionan piscinas y desayuno. El LLM ve datos incompletos, calcula a partir de muestras y retorna "aproximadamente 120 hoteles" (fabricado a partir de 3 fragmentos de 200 hoteles).

Las consultas fuera de dominio retornan respuestas alucinadas en lugar de admitir que no existen datos.

La Solución

Reemplaza la recuperación vectorial con consultas de grafos para datos estructurados. Almacena hoteles, amenidades y relaciones en Neo4j. El LLM traduce "hoteles con piscinas y desayuno" a Cypher:

MATCH (h:Hotel)-[:HAS_AMENITY]->(a:Amenity)
WHERE a.name IN ['pool', 'breakfast']
RETURN count(DISTINCT h)

Resultado: 133 hoteles (conteo exacto desde la base de datos).

Consulta fuera de dominio: "No se encontraron hoteles en la Antártida" en lugar de fabricar resultados.

Qué Decirle a Tu Asistente de IA

"Construye un agente de viajes usando GraphRAG con Neo4j. Para consultas 
estructuradas (hoteles, amenidades, disponibilidad), traduce a Cypher 
y ejecuta contra el grafo. Solo usa RAG vectorial para descripciones 
no estructuradas. Retorna conteos exactos desde recorrido del grafo."

Cuándo Usar

Datos estructurados con relaciones (productos, inventario, ubicaciones)
Consultas que requieren conteos, agregaciones o recorrido multi-salto
Dominios donde fabricar estadísticas crea riesgo legal/financiero

Detalles completos: RAG vs GraphRAG: When Agents Hallucinate Answers

Aprende más: Documentación Neo4j Cypher

Patrón 2: Semantic Tool Selection

¿Qué Es Semantic Tool Selection?

Semantic tool selection usa embeddings vectoriales para filtrar herramientas antes de que el LLM las vea. Cuando tu agente tiene más de 10 herramientas, enviar todas las descripciones en cada llamada aumenta las tasas de error (el agente elige herramientas incorrectas) y los costos de tokens (pagando por descripciones no usadas). El filtrado semántico inserta descripciones de herramientas offline, luego en tiempo de ejecución compara la consulta con las 5 herramientas más relevantes, reduciendo errores en 86.4% y costos en 89%.

Qué Se Rompe

Con 50 herramientas, ocurren dos fallas: (1) el agente elige herramientas incorrectas porque las descripciones se superponen, y (2) los costos de tokens explotan por enviar las 50 descripciones de herramientas en cada llamada al LLM.

Impacto medido: Las tasas de error aumentan con el conteo de herramientas, los costos de tokens escalan linealmente.

La Solución

Usa embeddings vectoriales para filtrar herramientas antes de que el LLM las vea. Inserta descripciones de herramientas offline. En tiempo de ejecución, inserta la consulta del usuario, calcula similitud, pasa solo las 5 herramientas más relevantes al agente.

Resultados en producción:

Errores reducidos: 86.4%
Costos de tokens reducidos: 89%
Latencia: <10ms para filtrado de herramientas

Qué Decirle a Tu Asistente de IA

"Construye un agente multi-herramienta con semantic tool selection. Usa FAISS 
y SentenceTransformers para insertar descripciones de herramientas offline. En 
tiempo de ejecución, inserta la consulta, recupera las 5 herramientas más similares, 
pasa solo esas al agente. Mantén memoria de conversación, intercambia herramientas dinámicamente."

Cuándo Usar

Agentes con más de 10 herramientas
Herramientas con descripciones que se superponen
Aplicaciones sensibles a costos

Detalles completos: Reduce Agent Errors and Token Costs with Semantic Tool Selection

Patrón 3: Neurosymbolic Guardrails (Bloqueo)

¿Qué Son Neurosymbolic Guardrails?

Neurosymbolic guardrails aplican reglas de negocio a nivel de framework, por debajo del control del LLM. Cuando los prompts solos no pueden aplicar restricciones (máximo de huéspedes, fechas válidas, límites de presupuesto), los guardrails usan hooks de pre-ejecución para validar parámetros y cancelar operaciones inválidas. Las reglas viven en código, no en prompts, así que el LLM no puede evadirlas. Usa guardrails de bloqueo para restricciones duras que no pueden violarse.

Qué Se Rompe

Los prompts no pueden aplicar reglas de negocio. Incluso con docstrings claros ("max_guests debe ser ≤10"), el LLM pasa max_guests=15 bajo presión porque los prompts son sugerencias, no restricciones. El agente viola reglas silenciosamente.

La Solución

Usa hooks de framework para validar parámetros antes de la ejecución de herramientas. Si la validación falla, cancela la llamada de herramienta y retorna guía correctiva. Las reglas viven en código a nivel de framework, por debajo del control del LLM.

Impacto medido: Cero violaciones en prueba de 100 consultas (vs. 12 violaciones solo con prompts).

Qué Decirle a Tu Asistente de IA

"Construye un agente de reservas con guardrails usando hooks de Strands Agents. 
Crea un hook BeforeToolCallEvent que valide:
- max_guests ≤ 10
- check_in_date > hoy
- budget > 0

Si la validación falla, cancela la llamada de herramienta con event.cancel_tool() 
y retorna mensaje de error. No confíes en prompts para validación."

Cuándo Usar

Reglas de negocio que no pueden violarse (cumplimiento, legales, financieras)
Validación que requiere cálculo (matemáticas de fechas, verificaciones de inventario)
Reglas que cambian frecuentemente

Detalles completos: AI Agent Guardrails: Rules That LLMs Cannot Bypass

Patrón 4: Runtime Guardrails (Dirigir, No Bloquear)

¿Qué Es Dirigir vs Bloquear?

Steering guardrails retornan guía correctiva en lugar de bloquear operaciones. Cuando el agente viola una regla suave (problemas de formato, ajustes de parámetros, redacción de datos), el steering retorna instrucciones vía Guide() para que el agente se autocorrija y reintente. Esto difiere de los guardrails de bloqueo (Patrón 3) que detienen flujos de trabajo completamente. Usa steering para reglas donde el agente puede corregirse, bloqueo para restricciones duras.

Qué Se Rompe

Los guardrails duros (Patrón 3) bloquean operaciones y detienen flujos de trabajo. Para reglas suaves donde el agente puede autocorregirse (problemas de formato, ajustes de parámetros, redactar datos sensibles), el bloqueo crea fricción. El agente podría arreglar el problema por sí mismo si se le da guía.

La Solución

Usa Agent Control para retornar guía correctiva vía Guide() en lugar de bloquear. Cuando el agente viola una regla suave, el plano de control retorna instrucciones: "Ajusta el parámetro X a Y y reintenta." El agente se autocorrige y completa la tarea sin intervención humana.

Diferencia con el Patrón 3:

Bloquear (Patrón 3): Restricciones duras, el flujo de trabajo se detiene
Dirigir (Patrón 4): Reglas suaves, el agente se autocorrige

Qué Decirle a Tu Asistente de IA

"Construye un agente de reservas con Agent Control para reglas suaves. Conéctate 
al servidor Agent Control. Para reglas suaves (formato de parámetros, ajustes 
de fecha, redacción de datos), retorna Guide() con instrucciones de corrección 
en lugar de bloquear. El agente debe reintentar con la corrección aplicada.

Usa bloqueos duros (Patrón 3) solo para reglas de cumplimiento que no pueden 
violarse bajo ninguna circunstancia."

Cuándo Usar

Reglas donde el agente puede autocorregirse (formato, ajustar parámetros)
Flujos de trabajo donde el bloqueo crea UX pobre
Reglas gestionadas centralmente vía API/dashboard (actualizar sin redesplegar)

Detalles completos: Runtime Guardrails for AI Agents: Steer, Don't Block

Patrón 5: Multi-Agent Validation

¿Qué Es Multi-Agent Validation?

Multi-agent validation despliega agentes especializados con diferentes roles (Executor, Validator, Critic) que verifican cruzadamente el trabajo de los demás. Los agentes únicos optimizan para parecer exitosos, no verificar resultados. Múltiples agentes con diferentes funciones de optimización atrapan errores que los demás pierden. El Executor realiza tareas, el Validator verifica contra la verdad fundamental, el Critic proporciona revisión final antes de retornar al usuario.

Qué Se Rompe

Los agentes únicos no pueden autovalidarse. Cuando un agente reserva un hotel, afirma "Éxito: Reservado Grand Plaza Hotel" incluso si la API retornó un error o el hotel no existe en la base de datos. El agente optimiza para parecer exitoso, no verificar resultados.

La Solución

Despliega múltiples agentes con diferentes roles: el Executor realiza tareas, el Validator verifica contra la verdad fundamental, el Critic proporciona revisión final. Los agentes comparten contexto y transfieren control autónomamente cuando su rol se completa.

Impacto medido: Multi-agente atrapa errores que el agente único pierde (p.ej., reservar hoteles inexistentes).

Qué Decirle a Tu Asistente de IA

"Construye un sistema multi-agente usando Strands Swarm con 3 agentes:
1. Executor: Reserva hoteles, busca vuelos
2. Validator: Verifica cruzadamente operaciones contra la base de datos
3. Critic: Revisión final antes de retornar al usuario

Los agentes comparten contexto vía swarm.context. Usa transferencias autónomas. 
Los agentes deciden cuándo transferir según completación de tarea."

Cuándo Usar

Operaciones de alto riesgo (financieras, médicas, legales)
Tareas donde "parece exitoso" difiere de "realmente exitoso"
Flujos de trabajo complejos con múltiples puntos de verificación

Detalles completos: How to Stop AI Agents from Hallucinating Silently with Multi-Agent Validation

Patrón 6: Memory Pointer Pattern

¿Qué Es el Memory Pointer Pattern?

El Memory Pointer Pattern almacena datos grandes fuera del contexto del LLM y pasa referencias cortas en su lugar. Cuando las herramientas retornan logs de más de 200KB o resultados de base de datos de 1000 filas, pasarlos directamente causa truncamiento silencioso. Los memory pointers almacenan datos en agent.state, retornan un puntero al LLM y proporcionan herramientas separadas que resuelven punteros para acceder a datos completos. IBM redujo de 20M tokens a 1,234 tokens usando este patrón.

Qué Se Rompe

El desbordamiento de ventana de contexto ocurre cuando las herramientas retornan más datos de los que el LLM puede procesar (logs de más de 200KB, resultados de base de datos de 1000 filas). El agente no colapsa. Trunca datos silenciosamente, pierde contexto, produce respuestas incompletas.

Caso real de producción (IBM Materials Science):

Antes: 20 millones de tokens, flujo de trabajo falló
Después: 1,234 tokens, flujo de trabajo exitoso

La Solución

Almacena datos grandes en agent.state, pasa referencias cortas al LLM. Las herramientas retornan punteros como "logs-app-server". Las herramientas subsiguientes resuelven punteros para acceder a datos completos. El LLM solo ve: "Datos almacenados como logs-app-server. Usa analyze_errors(pointer)."

Datos en contexto reducidos: 214KB → 52 bytes

Qué Decirle a Tu Asistente de IA

"Construye un agente de análisis de logs usando Memory Pointer Pattern. Cuando 
fetch_logs retorne más de 20KB:
1. Almacenar en agent.state con ID de puntero único
2. Retornar al LLM: 'Datos almacenados como logs-{app}. Usa analyze_logs(pointer).'
3. Implementar analyze_logs(pointer) que resuelva desde agent.state

Nunca pases datos grandes directamente al contexto del LLM."

Cuándo Usar

Herramientas que retornan salidas grandes (logs, consultas de base de datos, archivos)
Flujos de trabajo con múltiples pasos de procesamiento sobre los mismos datos grandes
Aplicaciones sensibles a costos

Detalles completos: AI Context Window Overflow: Memory Pointer Fix

Patrón 7: Async HandleId Pattern

¿Qué Es el Async HandleId Pattern?

El async handleId pattern previene que APIs externas lentas bloqueen tu agente. Cuando una API toma más de 30 segundos, las llamadas síncronas congelan todo el agente. Async handleId retorna un ID de trabajo inmediatamente, permitiendo que el agente continúe con otras tareas. Una herramienta check_status separada sondea por resultados cuando estén listos. Esto elimina errores de timeout 424 y mantiene los agentes responsivos.

Qué Se Rompe

Las APIs externas que toman más de 30 segundos bloquean el agente indefinidamente. Ninguna otra herramienta puede ejecutarse. Después de ~7 segundos, muchas implementaciones retornan errores de timeout 424, congelando el flujo de trabajo.

La Solución

Las herramientas retornan inmediatamente con un ID de trabajo en lugar de esperar. El agente almacena handleId y continúa. Una herramienta check_status(job_id) separada sondea por resultados asincrónicamente.

Impacto medido:

Antes: API de 18 segundos bloquea agente, timeout 424
Después: Herramienta retorna en menos de 1 segundo, agente sondea cuando está listo

Qué Decirle a Tu Asistente de IA

"Construye un agente con async handleId pattern para APIs lentas:

1. start_analysis(data): Envía trabajo, retorna job_id inmediatamente
2. check_status(job_id): Sondea por resultados

El agente llama start_analysis, almacena job_id, continúa con otras 
tareas, llama check_status cuando está listo. No implementes llamadas bloqueantes."

Cuándo Usar

APIs externas con tiempos de respuesta mayores a 5 segundos
Procesamiento por lotes (análisis de video, transformaciones grandes)
Cualquier sistema fuera de tu control

Detalles completos: Fix MCP Timeouts: Async HandleId Pattern

Patrón 8: DebounceHook + Explicit States

¿Qué Previene los Bucles de Razonamiento?

Los bucles de razonamiento ocurren cuando retroalimentación ambigua ("más puede estar disponible") señala que reintentar podría ayudar. Dos correcciones funcionan juntas: estados terminales explícitos (retornar SUCCESS/FAILED para que el LLM sepa cuándo detenerse) y DebounceHook (hook de framework que bloquea llamadas duplicadas). Las pruebas de producción mostraron que los estados explícitos redujeron las llamadas de 14 a 2, mientras que DebounceHook proporciona una red de seguridad para casos extremos.

Qué Se Rompe

Los agentes hacen bucle llamando a la misma herramienta repetidamente sin progreso. Retroalimentación ambigua como "Se encontraron 3 resultados. Más pueden estar disponibles" señala que reintentar podría ayudar. El agente hace bucle indefinidamente.

Caso real de producción: 847 pasos de razonamiento a $47/minuto, sin respuesta entregada.

La Solución (Dos Partes)

Parte A: Estados Terminales Explícitos

Retorna estados claros de SUCCESS o FAILED. Cambia "Más pueden estar disponibles" a "SUCCESS: Se encontraron todos los 3 vuelos coincidentes."

Parte B: Red de Seguridad DebounceHook

El hook de framework rastrea llamadas recientes a herramientas. Cuando el mismo par (tool_name, input) aparece dos veces, bloquea el tercer intento.

Impacto medido (demo de reserva de viajes):

Retroalimentación ambigua: 14 llamadas
SUCCESS explícito: 2 llamadas (reducción de 7x)
DebounceHook: 12 llamadas (2 bloqueadas)

Qué Decirle a Tu Asistente de IA

"Construye un agente de viajes con protección anti-bucle:

1. Todas las herramientas retornan estados explícitos:
   - SUCCESS: [completación clara]
   - FAILED: [error claro]
   Nunca retornes 'más puede estar disponible'

2. Implementa DebounceHook:
   - Rastrea las últimas 3 llamadas de herramientas como (tool_name, input)
   - Si el mismo par aparece dos veces, bloquea el tercer intento
   - Retorna 'BLOCKED: Duplicado detectado'

Esto previene bucles sin límites manuales de reintentos."

Cuándo Usar

Agentes propensos a bucles de reintento (búsqueda, agregadores de API)
Aplicaciones sensibles a costos donde reintentos ilimitados son costosos
Sistemas de producción donde bucles infinitos crean riesgo de disponibilidad

Detalles completos: How to Prevent AI Agent Reasoning Loops from Wasting Tokens

Errores Comunes

Error 1: Asumir Que los Valores Por Defecto Son Mejores Prácticas

Problema: "Construye un agente de producción" asume que el asistente sabe qué significa producción.

Solución: Especifica patrones: "Usa GraphRAG, guardrails, patrones async, etc..."

Error 2: Confiar Solo en Prompts para Validación

Problema: "Asegúrate de que max_guests < 10" en el prompt del sistema es ignorado bajo presión.

Solución: "Implementa hook BeforeToolCallEvent que valide y cancele llamadas inválidas."

Error 3: No Reconocer Cuándo Aplican los Patrones

Problema: El agente funciona en demo, se rompe en casos extremos.

Solución: Conoce los 8 patrones. Cuando veas alucinaciones, timeouts o bucles, reconocerás qué patrón lo resuelve.

Lo Que Esto Significa para el Desarrollo Asistido por IA

Los asistentes de IA seguirán mejorando en generar código funcional. Pero código funcional y arquitectura lista para producción siguen siendo objetivos diferentes.

La brecha no es la capacidad del asistente. Es la especificidad del prompt.

Cuando escribes "construye un agente de reservas," el asistente optimiza para código que compila y responde a consultas.

Cuando escribes "construye un agente de reservas usando GraphRAG para consultas estructuradas, guardrails para validación y patrones async para APIs de reservas," el asistente optimiza para código que compila, responde a consultas, previene alucinaciones, aplica reglas de negocio y maneja APIs lentas.

Estos 8 patrones son el vocabulario para comunicar intención de producción.

No implementas los 8. Aprendes qué resuelven. Cuando ves alucinaciones, reconoces que GraphRAG aplica. Cuando ves timeouts, reconoces que async handleId aplica. Cuando ves bucles, reconoces que estados explícitos + DebounceHook aplican.

Este conocimiento cambia cómo haces prompts a Kiro, Claude Code, Cursor y ChatGPT. En lugar de depurar fallas de caja negra en producción, especificas los patrones que las previenen durante la generación.

Aprende Más (Guías de Implementación Completas)

Cada patrón tiene una guía completa con código funcional:

GraphRAG: RAG vs GraphRAG: When Agents Hallucinate Answers
Semantic Tool Selection: Reduce Agent Errors and Token Costs
Neurosymbolic Guardrails: AI Agent Guardrails: Rules That LLMs Cannot Bypass
Runtime Guardrails (Steering): Runtime Guardrails for AI Agents: Steer, Don't Block
Multi-Agent Validation: Stop AI Agents from Hallucinating Silently
Memory Pointers: AI Context Window Overflow: Memory Pointer Fix
Async HandleId: Fix MCP Timeouts: Async HandleId Pattern
DebounceHook: Prevent AI Agent Reasoning Loops

Serie completa:

Cierre

Cada patrón en este post existe porque algo se rompió en producción. Agentes que alucinaron estadísticas en demos de clientes. Bucles que quemaron tokens a $47/minuto. Desbordamientos de contexto que truncaron datos críticos. Timeouts que congelaron flujos de trabajo.

Ahora sabes qué se rompe y cómo prevenirlo al hacer prompts correctamente.

Cuando le pides a Kiro, Claude Code o ChatGPT que construya un agente, puedes especificar qué patrones aplican. Esa es la diferencia entre prototipos que se rompen y agentes que escalan.

Úsalo.

Gracias!

🇻🇪🇨🇱 Dev.to Linkedin GitHub Twitter Instagram Youtube

Elizabeth Fuentes LFollow

I help developers build production-ready AI applications through hands-on tutorials and open-source projects.

Por Qué Fallan los Agentes de IA: 3 Modos de Fallo Que Cuestan Tokens y Tiempo

Elizabeth Fuentes L — Fri, 08 May 2026 23:19:28 +0000

Los agentes de IA no fallan como el software tradicional: no se bloquean con un stack trace. Fallan silenciosamente: devuelven respuestas incompletas, se congelan en APIs lentas o queman tokens llamando a la misma herramienta una y otra vez. El agente parece funcionar, pero la salida está mal, llega tarde o es costosa.

Esta serie cubre los tres modos de fallo más comunes con soluciones respaldadas por investigación. Cada técnica tiene una demostración ejecutable que mide la diferencia antes/después.

Código funcional: github.com/aws-samples/sample-why-agents-fail

Las demos usan Strands Agents con OpenAI (GPT-4o-mini). Los patrones son independientes del framework: aplican a LangGraph, AutoGen, CrewAI o cualquier framework que soporte llamadas a herramientas y hooks de ciclo de vida.

Esta Serie: 3 Soluciones Esenciales

Desbordamiento de Ventana de Contexto — Patrón de Puntero de Memoria para datos grandes
Herramientas MCP Que Nunca Responden — Patrón handleId asíncrono para APIs externas lentas
Loops de Razonamiento en Agentes de IA — DebounceHook + estados claros de herramientas para bloquear llamadas repetidas

¿Qué Sucede Cuando las Salidas de Herramientas Desbordan la Ventana de Contexto?

El desbordamiento de ventana de contexto ocurre cuando una herramienta devuelve más datos de los que el LLM puede procesar: logs del servidor, resultados de bases de datos o contenidos de archivos que exceden el límite de tokens. El agente no falla con un error. Se degrada silenciosamente: trunca datos, pierde contexto o produce respuestas incompletas.

Una investigación de IBM cuantifica esto: un flujo de trabajo de Ciencia de Materiales consumió 20 millones de tokens y falló. El mismo flujo con punteros de memoria usó 1,234 tokens y tuvo éxito.

La solución — Patrón de Puntero de Memoria: Almacena datos grandes en agent.state, devuelve un puntero corto al contexto. La siguiente herramienta resuelve el puntero para acceder a los datos completos:

from strands import tool, ToolContext

@tool(context=True)
def fetch_application_logs(app_name: str, tool_context: ToolContext, hours: int = 24) -> str:
    """Obtiene logs. Almacena datos grandes como puntero para evitar desbordamiento de contexto."""
    logs = generate_logs(app_name, hours)  # Podría ser 200KB+

    if len(str(logs)) > 20_000:
        pointer = f"logs-{app_name}"
        tool_context.agent.state.set(pointer, logs)
        return f"Datos almacenados como puntero '{pointer}'. Usa herramientas de análisis para consultarlo."
    return str(logs)

@tool(context=True)
def analyze_error_patterns(data_pointer: str, tool_context: ToolContext) -> str:
    """Analiza errores — resuelve puntero desde agent.state."""
    data = tool_context.agent.state.get(data_pointer)
    errors = [e for e in data if e["level"] == "ERROR"]
    return f"Se encontraron {len(errors)} errores en {len(set(e['service'] for e in errors))} servicios"

El LLM nunca ve los 200KB: solo ve "Datos almacenados como puntero 'logs-payment-service'" (52 bytes).

¿Por qué Strands Agents? La API de ToolContext proporciona agent.state como un almacén clave-valor nativo con alcance para cada agente: sin diccionarios globales, sin infraestructura externa. Para flujos multi-agente, invocation_state comparte datos entre agentes en un Swarm con la misma API.

Métrica	Sin punteros	Con Punteros de Memoria
Datos en contexto	214KB (logs completos)	52 bytes (puntero)
Comportamiento del agente	Trunca o falla	Procesa todos los datos
Errores detectados	Parcial	Completo

Demo completa: 01-context-overflow-demo — implementaciones de agente único y multi-agente (Swarm) con notebooks.

¿Por Qué los Agentes de IA se Congelan al Llamar APIs Externas?

Los agentes de IA se congelan cuando las herramientas MCP llaman a APIs externas lentas o que no responden. El agente se bloquea en la llamada a la herramienta, el usuario no ve progreso, y después de 7 segundos muchas implementaciones devuelven un error 424. MCP (Model Context Protocol) les da a los agentes la capacidad de llamar herramientas externas, pero no maneja timeout o reintentos por defecto.

La solución — Patrón handleId asíncrono: La herramienta devuelve inmediatamente un ID de trabajo. El agente consulta una herramienta separada check_status:

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("timeout-demo")
JOBS = {}

@mcp.tool()
async def start_long_job(task: str) -> str:
    """Devuelve handle inmediatamente — previene timeout."""
    job_id = str(uuid.uuid4())[:8]
    JOBS[job_id] = {"status": "processing", "task": task}
    asyncio.create_task(_process_job(job_id))  # Trabajo en segundo plano
    return f"Trabajo iniciado. Handle: {job_id}. Usa check_job_status para consultar."

@mcp.tool()
async def check_job_status(job_id: str) -> str:
    """Consulta estado del trabajo — devuelve 'processing' o 'completed' con resultado."""
    job = JOBS.get(job_id)
    if not job:
        return f"FAILED: Trabajo '{job_id}' no encontrado"
    return f"{job['status'].upper()}: {job.get('result', 'Todavía procesando...')}"

Escenario	Tiempo de respuesta	UX
API rápida (1s)	3s total	OK
API lenta (15s)	18s bloqueado	Agente congelado
API fallida	Error 424 después de 7s	Agente falla
handleId asíncrono	~4s (inmediato + consulta)	Agente responde

¿Por qué Strands Agents? El MCPClient se conecta a cualquier servidor MCP. El agente descubre herramientas en tiempo de ejecución vía list_tools_sync(): sin lista de herramientas codificada. Cuando el servidor MCP implementa el patrón asíncrono, el agente consulta automáticamente sin código de orquestación adicional.

Demo completa: 02-mcp-timeout-demo — servidor MCP local con los 4 escenarios y notebook.

¿Por Qué los Agentes de IA Repiten la Misma Llamada a Herramienta?

Los loops de razonamiento en agentes de IA ocurren cuando el agente llama a la misma herramienta repetidamente con parámetros idénticos, sin hacer progreso. La causa raíz es retroalimentación ambigua de la herramienta: respuestas como "puede haber más resultados disponibles" hacen que el agente piense que otra llamada producirá mejores resultados. Las investigaciones muestran que los agentes pueden hacer loops cientos de veces sin entregar una respuesta.

Solución 1 — Estados terminales claros: Las herramientas devuelven SUCCESS o FAILED explícito en lugar de mensajes ambiguos:

# Ambiguo (causa loops)
return f"Vuelos encontrados: {results}. Puede haber más resultados disponibles."

# Claro (el agente se detiene)
return f"SUCCESS: Vuelo {conf_id} reservado para {passenger}. Confirmación enviada."

Solución 2 — DebounceHook: Detecta y bloquea llamadas duplicadas a herramientas a nivel de framework:

from strands.hooks.registry import HookProvider, HookRegistry
from strands.hooks.events import BeforeToolCallEvent

class DebounceHook(HookProvider):
    """Bloquea llamadas duplicadas a herramientas en una ventana deslizante."""
    def __init__(self, window_size=3):
        self.call_history = []
        self.window_size = window_size

    def register_hooks(self, registry: HookRegistry) -> None:
        registry.add_callback(BeforeToolCallEvent, self.check_duplicate)

    def check_duplicate(self, event: BeforeToolCallEvent) -> None:
        key = (event.tool_use["name"], json.dumps(event.tool_use.get("input", {})))
        if self.call_history.count(key) >= 2:
            event.cancel_tool = f"BLOCKED: Llamada duplicada a {event.tool_use['name']}"
        self.call_history.append(key)
        self.call_history = self.call_history[-self.window_size:]

Estrategia	Llamadas a herramientas	Resultado
Retroalimentación ambigua (línea base)	14 llamadas	Sin respuesta definitiva
DebounceHook	12 llamadas (2 bloqueadas)	Completa con bloqueos
Estados SUCCESS claros	2 llamadas	Completado inmediato

¿Por qué Strands Agents? La API de HookProvider intercepta llamadas a herramientas vía BeforeToolCallEvent antes de que se ejecuten. Establecer event.cancel_tool bloquea la ejecución a nivel de framework: el LLM no puede omitirlo. Esto hace que los hooks sean componibles para apilar DebounceHook, LimitToolCounts y validadores personalizados en el mismo agente.

Demo completa: 03-reasoning-loops-demo — los 4 escenarios con hooks y notebook.

Requisitos Previos

Necesitas Python 3.9+, uv (un gestor de paquetes rápido de Python), y una clave API de OpenAI.

git clone https://github.com/aws-samples/sample-why-agents-fail
cd sample-why-agents-fail/stop-ai-agents-wasting-tokens

# Elige cualquier demo
cd 01-context-overflow-demo   # o 02-mcp-timeout-demo, 03-reasoning-loops-demo
uv venv && uv pip install -r requirements.txt
export OPENAI_API_KEY="tu-clave-aquí"

uv run python test_*.py

Cada demo es independiente con sus propias dependencias, script de prueba y notebook de Jupyter.

Preguntas Frecuentes

¿Cuáles son los modos de fallo más comunes en agentes de IA?

Los tres modos de fallo más comunes son el desbordamiento de ventana de contexto (la herramienta devuelve más datos de los que el LLM puede procesar), timeouts de herramientas MCP (APIs externas bloquean al agente indefinidamente) y loops de razonamiento (el agente repite la misma llamada a herramienta sin progresar). Cada modo de fallo causa desperdicio de tokens y degrada la calidad de respuesta.

¿Cómo reduzco los costos de tokens de un agente de IA?

Las dos técnicas más efectivas son los punteros de memoria y estados claros de herramientas. El Patrón de Puntero de Memoria almacena salidas grandes de herramientas en estado externo y pasa referencias cortas al contexto del LLM, reduciendo el uso de tokens de más de 200KB a menos de 100 bytes por llamada a herramienta. Estados terminales claros (SUCCESS/FAILED) en respuestas de herramientas previenen que el agente reintente operaciones completadas, lo que puede reducir las llamadas a herramientas de 14 a 2.

¿Puedo usar estos patrones con frameworks distintos a Strands Agents?

Sí. El Patrón de Puntero de Memoria funciona con cualquier framework que soporte contexto de herramientas (pasar estado entre herramientas). El patrón handleId asíncrono es un patrón de diseño de servidor MCP: funciona con cualquier agente compatible con MCP. DebounceHook requiere hooks de ciclo de vida, que están disponibles en LangGraph, AutoGen y CrewAI con APIs diferentes.

Referencias

Investigación

Solving Context Window Overflow in AI Agents — IBM Research, Nov 2025
Towards Effective GenAI Multi-Agent Collaboration — Amazon, Dec 2024
Resilient AI Agents With MCP — Octopus, May 2025
Language models can overthink — The Decoder, Jan 2025

Implementación

Strands Agent State — ToolContext and agent.state
Strands MCP Tools — Connect any MCP server
Strands Hooks — Lifecycle events and tool cancellation

¿Qué modo de fallo has encontrado en tus agentes? Comparte en los comentarios.

Gracias!

🇻🇪🇨🇱 Dev.to Linkedin GitHub Twitter Instagram Youtube

Elizabeth Fuentes LFollow

I help developers build production-ready AI applications through hands-on tutorials and open-source projects.

IAM Principal Cost Allocation para Amazon Bedrock (Novedad)

Hector Fernandez CloudparaTodo — Mon, 13 Apr 2026 07:30:00 +0000

Hace unos meses inicie una serie de posts sobre como gobernar el uso de IA en AWS. En la primera entrega de esta serie hablamos de cómo dar acceso gobernado a LLMs en AWS desde el día 0: IAM Policies, Guardrails, Inference Profiles y un mecanismo de corte de presupuesto por equipo. Si no la leíste, te recomiendo empezar por ahí.
Podcast: UNA API KEY para LLMs

Pero había un punto que me quedaba pendiente: no podíamos saber quién dentro de un equipo estaba generando el consumo. Cortábamos al equipo entero, y después había que armar una solución custom con Model Invocation Logging para identificar al responsable.

AWS acaba de resolver la parte de visibilidad de forma nativa.

¿Bloquear todo el acceso? Eso sigue siendo otro tema, y creo que de forma nativa sería complejo de implementar un proxy (por ahora).

¿Qué anunció AWS?

El 8 de Abril de 2026, Amazon Bedrock lanzó soporte para asignación de costos por IAM principal, hablando en criollo: por usuario o rol de IAM, directamente en Cost Explorer y en CUR 2.0 (Cost and Usage Report).

¡BIEN! Ahora podemos ver el costo desglosado de Bedrock en Cost Explorer sin muchas vueltas.
Anuncio oficial

Ahora, algo que debes tener claro desde ya: esta funcionalidad es de billing, no de enforcement. Los datos llegan a CUR 2.0 y Cost Explorer con 24-48 horas de latencia. Eso significa que puedes saber quién gastó cuánto, pero no puedes bloquear el acceso en tiempo real con esta data. Para eso, el Budget Cut Lambda de la Parte 1 sigue siendo necesario.

¿Qué cambia respecto a la Parte 1 que habíamos hablado?

En la primera publicación usamos Inference Profiles con tags (CostCenter, Team) para atribuir costos por equipo. Eso sigue siendo válido para agrupar por carga de trabajo. Pero ahora hay una capa adicional: la identidad del que hace la llamada.

Mecanismo	Granularidad	¿Qué resuelve?
Inference Profile + Resource Tags	Por equipo / carga de trabajo	"¿Cuánto gastó el equipo backend en Haiku?"
IAM Principal Cost Allocation (NUEVO)	Por usuario / rol	"¿Cuánto gastó `user@empresa.com` en todos los modelos?"

Juntando todo esto, tenemos: quién gastó cuánto, en qué modelo, para qué equipo. Pero recuerda: esta foto la ves con 24-48h de retraso. Es para análisis y chargeback, no para corte en tiempo real.

Pre-requisitos

Todo lo de la Parte 1 más (te invito a leerla)

Tags en tus IAM users/roles con atributos de negocio (team, business-unit, project)
Acceso a la consola de Billing and Cost Management (si es por Organizations, lo haces desde la cuenta management)
CUR 2.0 habilitado (el CUR legacy no soporta esto)

Paso 1: Taggear los IAM Principals

Si usas SSO, cada Permission Set genera un rol en la cuenta target con formato AWSReservedSSO_{PermissionSetName}_{hash}. Estos roles se pueden taggear.

"""
Taggea los roles SSO con atributos de negocio.
Estos tags son los que aparecerán en Cost Explorer y CUR 2.0.
"""
import boto3

iam = boto3.client("iam")

# Mapeo: role SSO -> tags de negocio
SSO_ROLES = {
    "AWSReservedSSO_BackendDev_a1b2c3d4": {
        "team": "backend",
        "business-unit": "BU-ENG-001",
        "department": "engineering",
        "environment": "development",
    },
    "AWSReservedSSO_FrontendDev_e5f6g7h8": {
        "team": "frontend",
        "business-unit": "BU-ENG-002",
        "department": "engineering",
        "environment": "development",
    },
    "AWSReservedSSO_DataTeam_i9j0k1l2": {
        "team": "data",
        "business-unit": "BU-DATA-001",
        "department": "data-science",
        "environment": "development",
    },
}

for role_name, tags_dict in SSO_ROLES.items():
    tags = [{"Key": k, "Value": v} for k, v in tags_dict.items()]

    iam.tag_role(RoleName=role_name, Tags=tags)
    print(f"✅ {role_name} taggeado con: {tags_dict}")

Si además tienen IAM Users (para casos legacy o service accounts), se taggean igual:

aws iam tag-user \
  --user-name "superuser-pipeline-sa" \
  --tags Key=team,Value=data Key=business-unit,Value=BU-DATA-001 Key=project,Value=recommendation-engine

Nota importante de AWS: Los tags solo aparecen para activación en la consola de Billing después de que el principal haya hecho al menos una llamada a Bedrock. Si taggeaste un rol pero nadie lo ha usado aún, no vas a verlo en Cost Allocation Tags.

Paso 2: Activar los tags como Cost Allocation Tags

Billing and Cost Management Console
    → Cost Organization 
        → Cost Allocation Tags (Etiquetas de asignación de costos)
            → Filtrar por "IAM principal type"
            → Seleccionar: team, business-unit, department
            → Click "Activate"

Después de activarlos, los tags tardan hasta 24 horas en estar disponibles para filtrado en Cost Explorer y CUR.

# Verificar qué tags están activos via CLI
aws ce list-cost-allocation-tags \
  --status Active \
  --tag-keys "team" "business-unit" "department" \
  --type "iamPrincipal"

Paso 3: Habilitar IAM Principal en CUR 2.0

Si hay un paso para que todo esto funcione, es este.

Activa la columna line_item_iam_principal en los reportes de costos.

Billing and Cost Management Console
    → Data Exports
        → Create export → Standard data export (CUR 2.0)
            → Additional export content:
                ✅ Include caller identity (IAM principal) allocation data
            → Destino: S3 bucket + Athena integration
        → Save

¿Qué genera esto? Cada línea del CUR 2.0 ahora incluye el ARN exacto del principal que hizo la llamada a Bedrock. Y los tags del principal aparecen con prefijo iamPrincipal/ para no colisionar con resource tags.

¿Cómo se ve la data?

En Cost Explorer: filtrar por equipo/usuario

Una vez activados los tags, Cost Explorer permite agrupar directamente:

Cost Explorer
    → Filtro: Service = "Amazon Bedrock"
    → Group by: Tag → "iamPrincipal/team"

Vas a ver algo como:

iamPrincipal/team    | Costo (USD)
---------------------|------------
backend              | $142.30
data                 | $89.50
frontend             | $23.10
(sin tag)            | $5.40

¿Y si quieres ver quién dentro del equipo backend está consumiendo más? Cambias el Group by:

Cost Explorer
    → Filtro: Service = "Amazon Bedrock"
    → Filtro: Tag "iamPrincipal/team" = "backend"
    → Group by: Tag → "iamPrincipal/business-unit"

BONUS

(Opcional) CUR 2.0 + Athena: análisis avanzado por usuario individual

Si Cost Explorer no te da suficiente granularidad y necesitas ver por usuario individual, puedes consultar CUR 2.0 directamente con Amazon Athena.

Sobre costos de Athena: Athena cobra $5 USD por TB escaneado (con el modo on-demand). Para CUR de organizaciones pequeñas/medianas esto suele ser centavos por consulta. Si quieres reducir costos, activa la compresión del CUR (formato Parquet) y particiona por mes. También existe el modo Provisioned Capacity para uso intensivo.

-- ¿Quiénes son los top 10 consumers de Bedrock este mes?
SELECT
    line_item_iam_principal AS iam_principal,
    tags['iamPrincipal/team'] AS team,
    tags['iamPrincipal/business-unit'] AS business_unit,
    line_item_product_code,
    SUM(line_item_unblended_cost) AS total_cost,
    SUM(line_item_usage_amount) AS total_usage
FROM cur_2_0.bedrock_usage
WHERE
    line_item_product_code = 'AmazonBedrock'
    AND EXTRACT(MONTH FROM billing_period) = EXTRACT(MONTH FROM CURRENT_DATE)
GROUP BY 1, 2, 3, 4
ORDER BY total_cost DESC
LIMIT 10;

Resultado:

iam_principal                                          | team     | business_unit | total_cost
-------------------------------------------------------+----------+---------------+-----------
arn:aws:sts::123456:assumed-role/BackendDev/javier@...  | backend  | BU-ENG-001    | $67.30
arn:aws:sts::123456:assumed-role/DataTeam/maria@...     | data     | BU-DATA-001   | $52.10
arn:aws:sts::123456:assumed-role/BackendDev/luis@...    | backend  | BU-ENG-001    | $41.20
...

Sin proxies, sin Lambdas, sin CloudTrail scraping: sabes exactamente que Javier del equipo backend gastó $67.30 este mes.

Recuerda que cada ejecución tiene un costo mínimo en Athena, pero para un CUR particionado en Parquet suele ser menos de $0.01 por consulta.

Recap ¿Cómo se complementa con la Parte 1?

Componente	Parte 1	Parte 2 (lo nuevo)
¿Quién puede usar qué modelo?	IAM Policy per-team	Sin cambios
¿Se protege PII?	Bedrock Guardrails	Sin cambios
¿Cuánto gastó cada equipo?	Inference Profile tags → Cost Explorer	IAM Principal tags → Cost Explorer (más granular)
¿Cuánto gastó cada usuario?	❌ No disponible	✅ `line_item_iam_principal` en CUR 2.0
¿Se corta al exceder presupuesto?	Budget Cut Lambda (per-team, ~10 min)	⚠️ CUR tiene 24h de delay. NO sirve para bloquear. El Budget Cut Lambda sigue siendo el único mecanismo de corte

Lo que sigue sin resolver nativamente

Seamos honestos: hay cosas que necesitan un proxy real, y para dar gobierno a la IA es lo mejor que puedes pensar.

Corte per-user en tiempo real: CUR tiene 24h de delay. Si necesitas cortar a un usuario específico en minutos, necesitas Model Invocation Logging + Lambda + iam:PutRolePolicy dirigido al session principal
Caching de respuestas: No hay caching nativo de Bedrock. Un proxy como LiteLLM puede cachear respuestas repetitivas y ahorrar costos
Multi-provider routing: Si quieres probar OpenAI y Anthropic directamente (no vía Bedrock), necesitas una capa de abstracción
Observabilidad semántica: Para ver el árbol de razonamiento de un agente, necesitas OTel + Langfuse. CloudTrail te dice "quién llamó", pero no "por qué razonó así"

La clave es que los tags del principal (quién) y los tags del recurso (qué) se complementan en CUR 2.0. No se pisan porque CUR los distingue con prefijos: iamPrincipal/team vs resourceTag/Team.

Conclusiones

Con este anuncio, el modelo de gobierno nativo que planteamos en la Parte 1 gana una pieza que faltaba: visibilidad de costos por usuario, sin añadir infraestructura, sin scraping de CloudTrail, sin Lambdas custom para atribución. Es una herramienta de análisis y chargeback, no de enforcement. El bloqueo en tiempo real sigue dependiendo del Budget Cut Lambda y CloudWatch.

Siempre pensemos en etapas:

Día 0: IAM Policies + Guardrails + Inference Profiles → acceso gobernado
Día 1: Budget Cut Lambda, protección contra gastos descontrolados
Ahora (Día 2): IAM Principal Cost Allocation, saber exactamente quién gasta qué

¿Falta mucho por hacer? Sí. Un proxy real (LiteLLM), observabilidad semántica (Langfuse), y caching siguen siendo evoluciones deseables si la organización escala. Pero la base está puesta, y es 100% nativa.

Lo bueno de todo esto: AWS sigue mejorando sus productos, pero nosotros como arquitectos debemos de saber identificar el uso para nuestras necesidades.

Hoy es cost allocation por principal. Mañana quizás sea throttling per-user nativo o guardrails a nivel de servicio que no requieran guardrailConfig en el código del dev.

Lo que conoces hoy en día en cloud no queda de un lado, todo ese conocimiento es MUY necesario para disponibilizar IA de forma responsable y sobre todo cuantificable.

¿Te gustaría que estemos en 📩 contacto?
Te espero en LinkedIn o desde el Podcast: Cloud para Todos

Héctor Fernández
AWS Community Builder

https://podcast.hectorfernandez.dev

DEV Community: AWS Español

Cómo Prevenir Loops de Razonamiento en Agentes de IA y No Desperdiciar Tokens

Serie: Por Qué Fallan los Agentes de IA

El Problema: Agentes Que Piensan Demasiado

Por Qué Ocurren los Loops: Retroalimentación Ambigua de Herramientas

Solución 1: Debounce Hook con Strands

Solución 2: Estados SUCCESS/FAILED Claros

Solución 3: Límites Duros con LimitToolCounts

Resultados de la Demo

Cuándo Usar Cada Solución

Pruébalo Tú Mismo

Conclusiones Clave

Preguntas Frecuentes

¿Por qué los agentes de IA repiten la misma llamada a herramienta?

¿Qué es un DebounceHook y cómo previene loops de razonamiento?

¿Cómo reducen los estados SUCCESS/FAILED claros las llamadas a herramientas?

Referencias

Investigación

Implementación

Elizabeth Fuentes LFollow

CLI vs MCP: guía para agentes en producción

¿Qué son MCP y CLI?

MCP (Model Context Protocol)

CLI (Command-Line Interface)

El problema que detonó el debate: MCP devora contexto

El ejemplo concreto

Anthropic mismo lo reconoció

La chispa: Peter Steinberger y OpenClaw

Las tres voces que estructuraron el debate

1. David Zhang (Duet) y el "trilemma"

2. Cobus Greyling y la tesis del "puente que ya existe"

3. Anthropic y el contraataque: Code Execution with MCP

¿Por qué CLI funciona tan bien para LLMs?

1. Los LLMs ya saben usar CLI "de memoria"

2. CLI tiene "divulgación progresiva" gratis

3. Composabilidad tipo Unix

4. Cero overhead de protocolo

- MCP: negocia capacidades → carga esquemas → construye llamada → servidor ejecuta → wrap del resultado → parse. Cada paso suma tokens.

La comparación honesta: ¿cuándo gana cada uno?

El framework de decisión que se puede implementar

Lo que realmente está pasando: no es una guerra, es una corrección

¿Qué hacemos en el curso?

Preguntas frecuentes

¿MCP está muerto?

¿Cuándo conviene MCP sobre CLI?

¿Es seguro darle bash a un agente?

¿El patrón Code Execution reemplaza a MCP?

¿Cómo afecta esto a Strands Agents, LangChain, CrewAI?

Recursos para profundizar

Cómo Evaluar Agentes IA: Tutorial de LLM-as-Judge

¿Por Qué Strands Agents Para Evaluar Agentes IA?

Por Qué Fallan Las Métricas Binarias

¿Cómo Funciona la Evaluación LLM-as-Judge?

El Problema con Prompts Vagos

La Solución: Criterios de Puntuación Explícitos

Rúbricas Vagas vs Específicas: Una Comparación

Mezclando Jueces LLM con Verificaciones Determinísticas

Hallazgos Clave de la Investigación

¿Qué Es la Evaluación de Trayectorias?

El Problema: La Evaluación de Solo Salida Está Ciega

La Solución: Evalúa el Camino, No Solo el Destino

Captura Automática de Trayectorias con Hooks

Investigación Reciente: ¿Qué Hay de Nuevo en Abril de 2026?

1. D3-Gym: Tareas Científicas Ejecutables

2. WindowsWorld: Benchmark de Agentes GUI

3. CARE: Ingeniería Colaborativa de Razonamiento de Agentes

Amazon Bedrock AgentCore: Evaluación Lista para Producción

Evaluadores Integrados

Observabilidad

Cuándo Usar AgentCore vs Strands Evaluation

Combinando LLM-as-Judge y Evaluación de Trayectorias

Pruébalo Tú Mismo

Preguntas Frecuentes

¿Cómo elijo entre LLM-as-Judge y verificaciones determinísticas?

¿Qué pasa si mi agente usa más de 50 herramientas? ¿Escala la evaluación de trayectorias?

¿Puedo usar evaluación de trayectorias con LangGraph o AutoGen?

¿Con qué frecuencia debo ejecutar evaluaciones?

Puntos Clave

¿Qué Sigue?

Referencias

- MCP: `negocia capacidades → carga esquemas → construye llamada → servidor ejecuta → wrap del resultado → parse`. Cada paso suma tokens.