DEV Community: AWS Español

Memoria de Agentes de IA: Conversación vs Contexto

Elizabeth Fuentes L — Wed, 17 Jun 2026 00:25:37 +0000

Tu agente quema su presupuesto de tokens en una sola llamada a una herramienta, o se olvida de lo que el usuario dijo hace tres turnos. Misma causa raíz: tiene dos tipos de memoria y se mezclaron. Una guarda la conversación; la otra guarda salidas grandes de herramientas, como logs. Necesitan almacenamiento distinto y recuperación distinta, y tratarlas como un solo almacén es lo que hace a los agentes lentos, caros y equivocados.

Este post muestra cómo mantenerlas separadas: el framework ahora descarga los datos grandes por ti (se acabó el código de punteros a mano), y en producción las dos memorias se mapean a dos servicios de AWS. Lo desplegué y medí la diferencia.

Continúa AI Context Window Overflow: Memory Pointer Fix. El código usa Strands Agents; los patrones se trasladan a otros frameworks. Repo: sample-why-agents-fail.

¿Cuáles son los dos tipos de memoria de un agente?

Un agente de IA tiene dos tipos de memoria: la memoria de conversación guarda lo que se dijo (turnos, preferencias, hechos) y se recupera por significado, mientras que la memoria de contexto guarda salidas grandes de herramientas (logs, datasets, documentos) y se recupera por un identificador exacto. Son almacenes distintos con recuperación distinta, y usar uno donde corresponde el otro es la causa raíz tanto de "mi agente se olvida de las cosas" como de "mi agente reventó el presupuesto de tokens".

Antes de cualquier código, deja clara la distinción:

	Memoria de conversación	Memoria de contexto
Guarda	Turnos, preferencias, hechos extraídos	Salidas grandes de herramientas (logs, datasets)
Se recupera por	Significado (similitud semántica)	Identificador exacto (una referencia)
Pregunta que responde	"¿Qué me dijo el usuario antes?"	"Devuélveme ese archivo de log de 5 MB, exacto"
Mal encaje para	Un blob de log de 5 MB	"¿Cuál era el nombre del usuario?"

Esa tabla es todo el artículo. Lo que sigue es solo dónde vive cada fila en el código.

Por qué la memoria de contexto se desborda primero

Las salidas grandes de herramientas desbordan la ventana de contexto porque son indivisibles y se reenvían en cada llamada al modelo. Una herramienta que devuelve 200 KB de logs no cuesta 200 KB una sola vez. Ese payload viaja en la entrada de cada turno posterior hasta que empuja la pregunta original fuera de la ventana.

El primer post lo cuantificó con investigación de IBM (Solving Context Window Overflow in AI Agents, 2025): un flujo de ciencia de materiales que consumía 20.822.181 tokens y fallaba bajó a 1.234 tokens y tuvo éxito una vez que los datos grandes se almacenaron fuera del contexto y se referenciaron con un puntero.

El arreglo, antes y ahora: deja de poner datos en la conversación

El post original almacenaba los datos grandes a mano: una herramienta los escribía en agent.state y devolvía una cadena-puntero corta; la siguiente herramienta los leía de vuelta con esa clave. Funciona, pero la lógica de descarga vivía dentro de cada herramienta.

Strands ahora trae ese mismo patrón como un plugin de primera clase, ContextOffloader, así que tus herramientas vuelven a ser funciones ordinarias:

from strands import Agent
from strands.vended_plugins.context_offloader import ContextOffloader, FileStorage

# Herramientas ordinarias — sin lógica de punteros, sin agent.state dentro
agent = Agent(
    model=MODEL,
    tools=[fetch_application_logs, count_errors_by_service],
    plugins=[ContextOffloader(storage=FileStorage("./artifacts"),
                              max_result_tokens=800, preview_tokens=200)],
)
agent("Fetch 2 hours of logs for 'api-gateway' and tell me the top error service.")

Cuando el resultado de una herramienta supera max_result_tokens, el plugin lo intercepta, almacena cada bloque en el backend y deja un pequeño preview más una referencia en el contexto. El agente obtiene una herramienta retrieve_offloaded_content(reference) para traer de vuelta los datos completos por referencia exacta cuando realmente los necesita.

¿Qué es el patrón Memory Pointer nativo en Strands?

El patrón Memory Pointer nativo es ContextOffloader, un plugin que intercepta resultados de herramientas demasiado grandes en tiempo de ejecución, almacena cada bloque en un backend de almacenamiento y reemplaza el resultado en contexto con un preview más una referencia. Los datos grandes nunca inundan la ventana de contexto, y tus herramientas nunca tocan lógica de punteros.

Resultados medidos

Corrí la misma consulta con tres estrategias. Misma consulta, gpt-4o-mini, 2 horas de logs:

Estrategia	Tokens en contexto
Sin gestión	~18.000 a 20.000
`ContextOffloader` (FileStorage)	~490
`context_manager="auto"`	~1.000

Eso es aproximadamente 97% menos tokens para la misma respuesta. Los números varían por ejecución porque los datos de log son aleatorios; test_native_pointer.py los reproduce.

Una salvedad honesta: el offloader es una red de seguridad, no la victoria completa. El gran ahorro viene de combinarlo con una herramienta selectiva. Mi count_errors_by_service calcula la respuesta del lado del servidor y devuelve un resumen pequeño, así el agente responde desde el resumen y los logs se quedan descargados. Sin una herramienta selectiva, un agente que necesite el dataset completo simplemente llamará a retrieve_offloaded_content y lo traerá todo de vuelta. El offloader garantiza que no desbordes; las herramientas selectivas son las que mantienen bajo el conteo de tokens.

Una línea para la mayoría de los agentes

Para un agente típico de múltiples turnos no configuras la descarga y el resumen por separado:

agent = Agent(model=MODEL, tools=[...], context_manager="auto")

Esto compone un SummarizingConversationManager (resume el historial antiguo con compresión proactiva) y un ContextOffloader (en memoria) con valores por defecto validados por benchmark. Lo que pases explícitamente tiene prioridad.

La misma idea, sobre almacenamiento real en Amazon S3

FileStorage escribe en disco local. Cambia una línea y las salidas grandes de herramientas aterrizan en un bucket S3 real, recuperadas por referencia exacta, nunca en la ventana:

from strands.vended_plugins.context_offloader import ContextOffloader, S3Storage

agent = Agent(
    model=MODEL,
    tools=[fetch_application_logs, count_errors_by_service],
    plugins=[ContextOffloader(S3Storage(bucket=CONTEXT_BUCKET, prefix="log-artifacts/"))],
)

Un dataset de logs de 83 KB se almacenó en S3, ~486 tokens quedaron en contexto, y los datos volvieron byte por byte por su referencia exacta:

📊 Tokens left in LLM context:  486
📦 Objects offloaded to S3:     1
   pointer in context:  s3://…/log-artifacts/1781569100199_1_call_…_0
   storage.retrieve()  → 77,050 bytes  (text/plain)
   verified: 200 log events recovered verbatim — exact data, no loss

Esa es la segunda fila de la tabla, en forma de producción: recuperación por identificador exacto. No quieres "los logs más parecidos a mi consulta". Quieres esos logs, exactos. Eso es almacenamiento de objetos, no búsqueda semántica.

Producción: dos memorias, a propósito

En producción la separación se vuelve arquitectura. Un agente en Amazon Bedrock AgentCore mantiene cada memoria donde corresponde:

Conversación → AgentCore Memory. Turnos, preferencias y hechos extraídos, recuperados por similitud semántica (RetrieveMemoryRecords: embeddings, top_k, score de relevancia), con alcance por usuario mediante actor_id. Conectado mediante el AgentCoreMemorySessionManager de Strands.
Memoria de contexto → Amazon S3. El mismo ContextOffloader, con S3Storage en vez de FileStorage. Recuperada por referencia exacta.

¿Por qué no poner los logs también en AgentCore Memory? Porque AgentCore Memory recupera la memoria semánticamente más parecida, que es exactamente lo equivocado para "devuelve este dataset textual por id". La conversación quiere significado; los datos quieren una clave exacta. Un agente, dos memorias, cada una haciendo lo que sabe hacer bien.

agent = Agent(
    model=BedrockModel(region_name=REGION),
    tools=[fetch_application_logs, count_errors_by_service],
    session_manager=AgentCoreMemorySessionManager(memory_config, REGION),     # conversación
    plugins=[ContextOffloader(S3Storage(bucket=CONTEXT_BUCKET, prefix="…"))],  # datos
)

Observabilidad y evaluación vienen gratis

En AgentCore, la observabilidad completa está integrada. Agregas la librería de instrumentación y obtienes trazas, métricas y logs de cada invocación sin escribir nada de código de monitoreo. El despliegue ya la habilitó: el agente emite trazas y métricas de OpenTelemetry (OTEL) bajo el namespace bedrock-agentcore, y un panel de CloudWatch GenAI Observability muestra vistas de agente, sesión y trazas (latencia, tasa de error, uso de tokens, llamadas a herramientas) listas para usar.

Así diagnostiqué en segundos el error de permisos ListEvents de antes: la traza fallida estaba justo ahí en CloudWatch, sin configuración extra. Ver Visualizar datos de observabilidad de agentes AgentCore.

La misma instrumentación alimenta AgentCore Evaluations: puntuación automatizada con LLM-como-juez de la finalización de tareas y la precisión de las llamadas a herramientas a partir de las mismas trazas, para que midas la calidad del agente de forma continua en lugar de solo en el lanzamiento.

Qué memoria, cuándo

¿Solo el problema de datos, local? ContextOffloader(FileStorage(...)). Herramientas ordinarias, sin código de punteros.
¿Un agente típico de múltiples turnos? context_manager="auto". Resumen más descarga en una línea.
¿Producción? AgentCore Memory para la conversación, ContextOffloader(S3Storage(...)) para los datos. Mantenlas separadas.
En cualquier caso: combina el offloader con herramientas selectivas que devuelvan resúmenes, no blobs crudos. El offloader previene el desbordamiento; las herramientas selectivas mantienen bajo el conteo de tokens.

Pruébalo tú mismo

Necesitas Python 3.11+, uv y una OPENAI_API_KEY (o cambia el modelo por BedrockModel). Los pasos de S3 y AgentCore también requieren credenciales de AWS.

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

uv run python test_native_pointer.py              # local, comparación medida de tokens
AWS_PROFILE=you uv run python test_s3_offload_local.py   # descarga real a S3
# Despliegue de producción + recorrido de dos memorias: setup_agentcore_s3.ipynb

Notebooks: test_native_pointer.ipynb (local) y setup_agentcore_s3.ipynb (provisionar + desplegar + invocar en AWS).

Puntos clave

Un agente tiene dos memorias. Conversación (semántica) y datos (referencia exacta). La mayoría de los problemas de contexto son una puesta donde corresponde la otra.
Ya no construyes el lado de datos a mano. ContextOffloader es el patrón Memory Pointer como plugin; las herramientas siguen siendo funciones ordinarias.
Medí ~97% menos tokens en este demo, y verifiqué un dataset de 83 KB descargado a S3 real y recuperado byte por byte por referencia.
En producción, mantén las dos memorias separadas. AgentCore Memory para conversación, S3 para datos. Recuperar logs por significado es el diseño equivocado.
El offloader es una red de seguridad; las herramientas selectivas son la victoria. Devuelve resúmenes, no blobs.
En AgentCore, la observabilidad y la evaluación son gratis. Agrega la librería y obtén trazas, métricas y puntuación con LLM-como-juez sin código de monitoreo.

Preguntas frecuentes

¿ContextOffloader necesita AWS? No. Con FileStorage o InMemoryStorage corre totalmente en local. Solo necesitas AWS cuando eliges S3Storage o despliegas en AgentCore.

¿Puedo guardar archivos grandes en AgentCore Memory en vez de S3? Puedes, pero no deberías. AgentCore Memory recupera por similitud semántica, así que devuelve la memoria más parecida, no un archivo exacto. Las salidas grandes de herramientas necesitan recuperación por identificador exacto, que es lo que da S3 (mediante ContextOffloader).

¿Necesito Docker para desplegar en AgentCore? No. El starter toolkit construye la imagen en la nube con AWS CodeBuild por defecto. Docker solo se necesita para una compilación local.

¿Cuál es la diferencia entre agent.state y ContextOffloader? agent.state es el patrón Memory Pointer manual: escribes y lees punteros dentro de tus herramientas. ContextOffloader es la misma idea como plugin: las herramientas siguen siendo ordinarias y el framework descarga los resultados grandes por ti.

¿Cuál de mis dos memorias me está costando tokens? La de datos. La memoria de conversación es texto pequeño; las explosiones de tokens vienen de las salidas grandes de herramientas viajando en el contexto. Esa es la memoria que arregla ContextOffloader.

¿Cuál de las dos memorias de tu agente está fugando tokens? Cuéntame en los comentarios.

Referencias

Investigación

Solving Context Window Overflow in AI Agents — IBM Research, 2025
Towards Effective GenAI Multi-Agent Collaboration — Amazon, 2024 (referenciación de payloads entre agentes)

Implementación

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.

AWS Agent Toolkit: Evita que tu Agente de IA Alucine APIs

Elizabeth Fuentes L — Fri, 12 Jun 2026 20:08:28 +0000

Tu agente de programación con IA alucina APIs de AWS porque está adivinando con datos de entrenamiento congelados en el pasado.

El Agent Toolkit for AWS arregla la fuente de verdad: le da a cualquier agente compatible con MCP documentación de AWS en vivo, skills probadas y guardrails. Aquí está el antes y después, y cómo instalarlo en un comando.

Pídele a un agente de programación que "configure un bucket de S3 con valores de seguridad razonables" y mira lo que pasa.

Escribe una política desde la memoria. La política usa un parámetro de API que cambió de nombre hace dos releases. El despliegue falla. El agente reintenta con una variación. También falla. Tres iteraciones después tienes un bucket que técnicamente existe, el bloqueo de acceso público a medias, y una transcripción que quemó unos cuantos miles de tokens en el camino.

Los agentes de programación con IA no fallan de forma ruidosa cuando tocan AWS. Fallan de forma plausible. El código se ve bien, los nombres de servicio son reales, y el error solo aparece al desplegar, o peor, en la revisión de seguridad.

¿Por qué los asistentes de programación con IA alucinan al escribir código de AWS?

Porque el modelo está adivinando con datos de entrenamiento congelados en el pasado. AWS lanzó servicios nuevos y cambió superficies de API después de ese corte, así que el agente recurre a lo que recuerda, no a lo que es cierto hoy. No sabe lo que no sabe, y no tiene forma de verificar antes de escribir.

¿Qué es el Agent Toolkit for AWS?

El Agent Toolkit for AWS es un toolkit oficial, soportado por AWS, que les da a los agentes de programación con IA las herramientas, el conocimiento y los guardrails que necesitan para construir, desplegar y operar aplicaciones en AWS. El AWS MCP Server que está debajo alcanzó disponibilidad general el 6 de mayo de 2026. Es open source (Apache-2.0).

Tiene cuatro componentes:

AWS MCP Server: un servidor gestionado de Model Context Protocol. Un solo endpoint con acceso a más de 15,000 operaciones de API de AWS (vía la herramienta call_aws, usando tus credenciales de IAM), más ejecución de scripts de Python en sandbox y búsqueda en la documentación que no necesita autenticación.
Agent skills: paquetes curados de instrucciones, scripts y material de referencia que el agente carga bajo demanda. El agente recupera solo lo relevante a la tarea actual, así que no gasta contexto. Piensa en "el procedimiento probado para configurar X", no en una adivinanza genérica.
Plugins: paquetes de instalación única para Claude Code y Codex que agrupan la configuración del MCP Server más un conjunto curado de skills. aws-core es el que se usa para empezar.
Rules files: configuración a nivel de proyecto que le dice al agente cómo trabajar en tu proyecto. Usar el MCP Server, descubrir skills, buscar en la documentación antes de actuar.

¿Por qué no dejar que el agente llame a AWS directamente?

Porque "directamente" significa "desde la memoria". El MCP Server cambia la fuente de verdad: de los datos de entrenamiento del modelo a la documentación y las APIs de AWS en vivo.

Dos cosas importan acá:

La búsqueda en documentación no necesita credenciales. El agente puede consultar la forma actual de hacer algo antes de escribir una línea de código. Para esa parte no se necesita cuenta de AWS.
La ejecución de scripts está en sandbox. Cuando el agente corre Python contra AWS, lo hace aislado de tu sistema de archivos y red local, y cada llamada queda registrada en CloudTrail con métricas en CloudWatch.

Ese segundo punto es el que los equipos pasan por alto. El MCP Server agrega dos condition keys a cada request, aws:ViaAWSMCPService y aws:CalledViaAWSMCP, para que tus políticas de IAM distingan una acción de un agente de una acción humana. Puedes mantener a un agente en solo lectura aunque el rol subyacente permita escrituras. El agente gana capacidad; tú mantienes el control.

Antes y después

Mismo prompt, mismo modelo. La única variable es el Toolkit.

	Agente solo	Agente + Toolkit
Fuente de verdad	Datos de entrenamiento (congelados)	Docs y APIs de AWS en vivo
Servicios obsoletos	Los elige en silencio	Las skills lo guían a los actuales
Despliegues fallidos	Reintenta, adivina, reintenta	Valida contra docs reales primero
Trazabilidad	Ninguna	CloudTrail + CloudWatch
Costo en tokens	Quemado en reintentos	Gastado una vez, correctamente

AWS describe el beneficio como agentes que construyen "con menos errores, menor costo de tokens, y controles de seguridad de nivel empresarial". El mecanismo detrás de eso es la tabla de arriba: el agente deja de improvisar desde la memoria obsoleta y empieza a actuar sobre documentación actual y procedimientos probados.

Ponlo a andar en tu agente

Necesitas uv instalado (ese es el comando uvx de abajo) y, para todo lo que efectivamente llame a AWS, credenciales locales de AWS. La búsqueda en documentación y el descubrimiento de skills funcionan sin credenciales.

Claude Code. El marketplace claude-plugins-official viene por defecto, así que un solo comando lo instala:

plugin install aws-core

Si dice "Plugin not found", actualiza primero el marketplace con /plugin marketplace update claude-plugins-official, y luego instala con el nombre explícito aws-core@claude-plugins-official.

Hay dos plugins más que vale la pena conocer: aws-agents (construir agentes con Bedrock y AgentCore) y aws-data-analytics (S3 Tables, Glue, Athena). Empieza con aws-core.

Codex:

codex plugin marketplace add aws/agent-toolkit-for-aws

Luego abre Codex y corre /plugins para instalar aws-core.

Kiro (o cualquier agente compatible con MCP). Agrega el servidor a .kiro/settings/mcp.json. Fija la versión para reproducibilidad y seguridad de la cadena de suministro:

{
  "mcpServers": {
    "aws": {
      "command": "uvx",
      "args": [
        "mcp-proxy-for-aws@1.6.0",
        "https://aws-mcp.us-east-1.api.aws/mcp",
        "--metadata", "AWS_REGION=us-west-2"
      ]
    }
  }
}

Y agrega las skills:

npx skills add aws/agent-toolkit-for-aws/skills

Cursor: Settings > Plugins > Team Marketplaces > Add Marketplace > Import from Repo, apuntando a aws/agent-toolkit-for-aws.

Funciona con cualquier agente compatible con MCP, y si estás construyendo agentes autónomos con frameworks como Strands, LangChain o Bedrock AgentCore, el mismo MCP Server es la interfaz de AWS que quieres por debajo de ellos.

Prueba el prompt del bucket otra vez

Instalé aws-core y volví a correr exactamente el mismo prompt. Esta vez el agente buscó en la documentación actual, sacó el procedimiento probado de una skill, y el bloqueo de acceso público quedó configurado correctamente en el primer intento. El parámetro obsoleto nunca apareció, porque el agente no estaba adivinando. Estaba leyendo.

Ese es todo el cambio: deja que tu agente deje de adivinar en AWS, y déjalo leer.

Está disponible sin costo adicional. Solo pagas por los recursos de AWS que realmente uses.

Este recorrido usa el Agent Toolkit for AWS, pero la idea de fondo (darle al agente una fuente de verdad en vivo y procedimientos probados en lugar de datos de entrenamiento congelados) es un patrón general de agentes que aplica a otras nubes y frameworks de agentes.

Preguntas frecuentes

¿Qué son las agent skills en el Agent Toolkit for AWS?
Las skills son paquetes curados de instrucciones, scripts y material de referencia que un agente recupera bajo demanda. En lugar de adivinar un procedimiento, el agente saca uno probado (por ejemplo, los pasos validados para asegurar un bucket de S3) en el momento que lo necesita.

¿Necesito una cuenta de AWS para usarlo?
No para todo. La búsqueda en documentación y el descubrimiento de skills funcionan sin credenciales. Solo necesitas credenciales locales de AWS cuando el agente hace llamadas reales a la API o corre scripts contra tu cuenta.

¿Qué agentes de programación soporta?
Claude Code, Codex y Cursor instalan los plugins directamente. Kiro y cualquier otro agente compatible con MCP pueden agregar el AWS MCP Server vía configuración. Si construyes agentes autónomos con frameworks como Strands, LangChain o Bedrock AgentCore, el mismo MCP Server es la interfaz de AWS por debajo.

¿En qué se diferencia de dejar que el agente use el AWS CLI?
El CLI ejecuta lo que sea que el agente adivinó. El Toolkit cambia la fuente de verdad primero: el agente consulta docs en vivo y skills probadas antes de actuar, corre scripts en un sandbox, y registra cada llamada en CloudTrail con métricas en CloudWatch.

¿Cuánto cuesta?
El Toolkit está disponible sin costo adicional. Solo pagas por los recursos de AWS que el agente realmente cree o use.

¿Qué flujo de trabajo de AWS es el que tu agente de programación hace mal más seguido? Cuéntame en los comentarios. Quiero ver si el Toolkit lo arregla.

Recursos

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.

5 patrones Multi-Agent con Strands Agents: cuál usar y cuándo

ricardoceci — Wed, 03 Jun 2026 11:43:51 +0000

Tenés un agente que busca vuelos. Otro que consulta el clima. Otro que aplica políticas corporativas. ¿Cómo los hacés trabajar juntos?

Strands Agents ofrece 5 patrones para coordinar múltiples agentes. Cada uno resuelve un problema distinto. La diferencia clave: quién decide el orden de ejecución. El modelo, los agentes entre sí, o vos en el código.

En este artículo explico cada patrón con código, muestro las diferencias con una tabla comparativa, y te doy un framework de decisión para elegir el correcto.

Todos los ejemplos usan Strands Agents (junio 2026). El código completo está en github.com/ricardoceci/curso-strands-agentcore-2026/tree/main/clase-3.

El caso de ejemplo: Travel Agent corporativo

Todos los ejemplos usan el mismo caso: un agente de viajes corporativo que coordina búsqueda de vuelos, consulta de clima, y generación de recomendaciones. Tres capacidades, tres agentes especializados.

from strands import Agent, tool

@tool
def search_flights(origin: str, destination: str, date: str) -> dict:
    """Search one-way flights via Duffel sandbox."""
    # ... llamada a la API de Duffel
    return {"route": f"{origin} -> {destination}", "offers": [...]}

@tool
def get_weather(city: str, target_date: str) -> dict:
    """Get weather forecast for a city on a specific date."""
    # ... llamada a Open-Meteo
    return {"city": city, "max_temp_c": 28, "precipitation_mm": 0.5}

Patrón 1: Agents as Tools

Un agente orquestador usa a otros agentes como si fueran tools. El orquestador decide cuándo delegar y a quién.

Cómo funciona

Pasás el sub-agente directo en el array de tools del agente principal. El SDK lo convierte a tool automáticamente. Cuando el modelo del orquestador decide que necesita esa capacidad, invoca al sub-agente. Todo corre en el mismo proceso Python.

Si necesitás más control, usá .as_tool() para customizar nombre y descripción, o el decorator @tool para wrappear la llamada completa.

# Sub-agente especializado en clima
weather_agent = Agent(
    tools=[get_weather],
    system_prompt="Sos un experto en clima. Respondé conciso.",
)

# El agente principal recibe al sub-agente directo en tools[]
travel_agent = Agent(
    tools=[search_flights, weather_agent],  # <-- el SDK lo convierte a tool
    system_prompt="Sos un asistente de viajes corporativos.",
)

response = travel_agent("Vuelos de EZE a MIA el 20 de agosto. ¿Cómo va a estar el clima?")

Cuándo usarlo

Cuando tenés pocos sub-agentes con capacidades claramente distintas y querés que el modelo principal decida cuándo llamar a cada uno. Es el patrón más directo. Requiere la menor coordinación.

Cuándo NO usarlo

Si necesitás que los agentes se comuniquen entre sí (no solo con el orquestador) o si el orden de ejecución importa. En esos casos, Graph o Swarm son mejores opciones.

Patrón 2: Swarm

Un grupo de agentes que se coordinan autónomamente mediante handoffs (transferencias de control). Cada agente decide cuándo pasarle el trabajo a otro.

Cómo funciona

Strands equipa a cada agente del Swarm con herramientas de coordinación: un handoff tool para transferir control a otro agente, y un shared context que todos pueden leer. Los agentes deciden solos el orden de ejecución.

from strands.multiagent import Swarm

flight_agent = Agent(
    name="flight_agent",
    tools=[search_flights],
    system_prompt="Buscás vuelos. Cuando termines, pasá el control al weather_agent.",
)

weather_agent = Agent(
    name="weather_agent",
    tools=[get_weather],
    system_prompt="Consultás el clima en destino.",
)

summary_agent = Agent(
    name="summary_agent",
    system_prompt="Combinás vuelos y clima en una recomendación clara.",
)

swarm = Swarm([flight_agent, weather_agent, summary_agent])

response = swarm("Necesito viajar de Buenos Aires a Miami el 20 de agosto")

Cuándo usarlo

Cuando el problema se descompone en partes que distintos especialistas resuelven mejor, y el orden puede variar según la tarea. Swarm es ideal para problemas donde no sabés de antemano qué agente debería actuar primero.

Cuándo NO usarlo

Si necesitás un flujo de ejecución predecible y repetible. Swarm decide el orden en runtime. Dos ejecuciones del mismo prompt pueden seguir caminos distintos.

Patrón 3: Graph

Un grafo dirigido donde cada nodo es un agente y las aristas definen el flujo de ejecución. Vos definís la estructura, el framework ejecuta en orden.

Cómo funciona

GraphBuilder te da una API para definir nodos (agentes) y aristas (conexiones). El framework pasa la salida de un nodo como entrada al siguiente. Soporta grafos acíclicos (pipelines) y cíclicos (loops de refinamiento), lo que te da flexibilidad para implementar iteraciones de revisión entre agentes.

from strands.multiagent import GraphBuilder

graph = (
    GraphBuilder()
    .add_node("search", flight_agent)
    .add_node("weather", weather_agent)
    .add_node("summary", summary_agent)
    .add_edge("search", "weather")
    .add_edge("weather", "summary")
    .build()
)

response = graph("Viaje de Buenos Aires a Miami, 20 de agosto")

Cuándo usarlo

Cuando el flujo de trabajo tiene un orden estricto que no debería cambiar. Por ejemplo: buscar vuelos primero, después consultar clima, después generar recomendación. Si el pipeline es el mismo cada vez, Graph es el patrón correcto.

Cuándo NO usarlo

Si necesitás flexibilidad en el orden de ejecución. Un Graph con muchos niveles de profundidad también suma latencia, porque cada nodo espera al anterior.

Patrón 4: Workflow

Un grafo de tareas con dependencias explícitas y ejecución paralela automática. Cada tarea se asigna a un agente con un system_prompt específico.

Cómo funciona

A diferencia de Graph (que opera con agentes como nodos), Workflow opera con tareas. Cada tarea tiene un ID, una descripción, dependencias, y prioridad. El framework resuelve el orden de ejecución, paraleliza lo que puede, y pasa resultados entre tareas.

from strands import Agent
from strands_tools import workflow

agent = Agent(tools=[workflow])

agent.tool.workflow(
    action="create",
    workflow_id="travel_planning",
    tasks=[
        {
            "task_id": "search_flights",
            "description": "Buscar los 5 vuelos más baratos de EZE a MIA el 20 de agosto",
            "system_prompt": "Sos un experto en búsqueda de vuelos.",
            "priority": 5,
        },
        {
            "task_id": "check_weather",
            "description": "Consultar el clima en Miami para el 20 de agosto",
            "system_prompt": "Sos un experto en clima.",
            "priority": 5,
        },
        {
            "task_id": "generate_report",
            "description": "Combinar vuelos y clima en un reporte ejecutivo",
            "dependencies": ["search_flights", "check_weather"],
            "system_prompt": "Sos un analista de viajes corporativos.",
            "priority": 3,
        },
    ],
)

agent.tool.workflow(action="execute", workflow_id="travel_planning")

En este ejemplo, search_flights y check_weather corren en paralelo (no tienen dependencias entre sí). generate_report espera a que ambos terminen.

Cuándo usarlo

Cuando tenés un proceso repetible con pasos que se pueden paralelizar. Workflow es el patrón más cercano a un pipeline de datos tradicional: dependencias explícitas, ejecución determinista, resultados que fluyen entre tareas.

Cuándo NO usarlo

Si necesitás que los agentes tomen decisiones sobre qué hacer a continuación. Workflow ejecuta exactamente lo que vos definiste, sin autonomía.

Patrón 5: A2A (Agent-to-Agent)

Un protocolo abierto (creado por Google, ahora en la Linux Foundation) para que agentes se comuniquen entre sí via HTTP. Los agentes pueden estar escritos en distintos frameworks, en distintos servidores.

Cómo funciona

Un agente se expone como servidor A2A con una Agent Card (metadata JSON en /.well-known/agent-card.json). Otro agente lo consume como cliente. La comunicación es HTTP/JSON.

Servidor:

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

weather_agent = Agent(
    name="weather_agent",
    description="Consulta pronósticos de clima por ciudad y fecha",
    tools=[get_weather],
)

a2a_server = A2AServer(agent=weather_agent)
app = a2a_server.to_fastapi_app()
uvicorn.run(app, host="0.0.0.0", port=9000)

Cliente:

from strands import Agent
from strands.agent.a2a_agent import A2AAgent

remote_weather = A2AAgent(
    agent_url="http://localhost:9000",
)

# Usarlo como nodo en un Graph
graph = (
    GraphBuilder()
    .add_node("search", flight_agent)
    .add_node("weather", remote_weather)
    .add_edge("search", "weather")
    .build()
)

Cuándo usarlo

Cuando los agentes viven en servidores distintos, están escritos en frameworks distintos (Strands, LangGraph, CrewAI), o pertenecen a equipos u organizaciones distintas. A2A es el único patrón que cruza la frontera del proceso local.

Cuándo NO usarlo

Si todos los agentes corren en el mismo proceso. A2A agrega latencia de red (50-1000ms por llamada, según benchmarks de la comunidad). Para comunicación local, los otros patrones son órdenes de magnitud más rápidos.

Comparación entre los 5 patrones Multi-Agent

Aspecto	Agents as Tools	Swarm	Graph	Workflow	A2A
Quién decide el orden	El modelo orquestador	Los agentes (handoffs)	Vos (aristas)	Vos (dependencias)	N/A (protocolo)
Comunicación	In-process	In-process	In-process	In-process	HTTP/JSON
Latencia	Microsegundos	Microsegundos	Microsegundos	Microsegundos	50-1000ms
Ejecución paralela	No nativa	Decidida por agentes	Soportada	Automática	N/A
Grafos cíclicos	No	No	Sí	No	No
Cross-framework	No	No	No	No	Sí
Composable	Sí (como tool)	Sí (nodo en Graph)	Sí (nodo en otro Graph)	No	Sí (nodo en Graph)

Framework de decisión

Cuando tenés que elegir un patrón, seguí estas preguntas:

¿Los agentes están en el mismo proceso?
Si no: A2A (es el único que cruza la red).

¿El orden de ejecución importa?
Si sí, ¿es siempre el mismo?: Graph (estructura fija).
Si sí, ¿con tareas paralelas?: Workflow (dependencias + paralelismo).

¿Los agentes necesitan decidir solos quién actúa?
Si sí: Swarm (handoffs autónomos).

¿Es delegación directa de un orquestador a especialistas?
Si sí: Agents as Tools (el más directo).

¿Ninguno encaja perfecto?
Los patrones se componen entre sí. Un Graph puede tener un Swarm como nodo. Un agente con tools puede incluir un A2AAgent remoto. Strands te deja mezclar patrones sin restricciones.

Preguntas frecuentes

¿Swarm usa A2A internamente?

No. Swarm usa llamadas de función Python dentro del mismo proceso. La confusión viene porque ambos involucran "comunicación entre agentes", pero Swarm es local (microsegundos) y A2A es remoto (HTTP).

¿Graph soporta ejecución condicional?

Sí. Las aristas pueden tener condiciones que se evalúan en runtime. Esto te da grafos que se comportan como árboles de decisión: según el output de un nodo, el flujo toma un camino u otro.

¿Puedo combinar patrones?

Sí, y es una de las fortalezas de Strands. Un Swarm puede vivir como nodo dentro de un Graph. Un Graph puede usar un A2AAgent remoto como nodo. Un agente con tools puede incluir otro agente como tool. La composición es libre.

¿Cuál es el más eficiente en tokens?

Agents as Tools y Graph consumen menos tokens porque la coordinación es determinista. Swarm puede consumir más porque los agentes razonan sobre a quién pasarle el control. A2A agrega overhead de protocolo HTTP.

¿Workflow reemplaza a Graph?

No. Workflow es una tool de Strands (viene de strands-agents-tools), mientras que Graph es un orquestador nativo del SDK. Workflow opera con tareas, Graph opera con agentes. Si necesitás que cada nodo sea un agente completo con su propio system prompt y tools, usá Graph. Si necesitás un pipeline de tareas con dependencias, usá Workflow.

Conclusión

Los 5 patrones no compiten entre sí. Cada uno resuelve una necesidad distinta de coordinación. La clave es empezar con el más directo que funcione para tu caso (probablemente Agents as Tools) y escalar hacia patrones más complejos cuando lo necesites.

Si querés ver estos patrones implementados en vivo con el caso del Travel Agent corporativo, están todos en el repositorio del curso:

github.com/ricardoceci/curso-strands-agentcore-2026

Y si querés aprender Strands desde cero, el curso completo (gratuito, en español) está en ricardoceci.dev.

Recursos

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.