Por qué la observabilidad de agentes ya no es opcional
¡Hola Devs! Subir un agente de IA sin observabilidad es como desplegar un microservicio sin logs. Ves la respuesta final, pero no tienes idea de por qué el modelo llamó a esa tool, por qué se fumó 40k tokens en un solo turno, o dónde se rompió el handoff al subagente.
El nuevo feature Agent Runs de Vercel resuelve justo eso para agentes basados en eve. Cuando despliegas un agente eve en Vercel, los traces se ingieren automáticamente — sin SDK que configurar, sin colector de OpenTelemetry que levantar. Cada sesión se convierte en un Agent Run consultable, con reasoning, tool calls y uso de tokens adjuntos.
Según el changelog oficial, esto ahora se expone por dos caminos: el Vercel MCP, para agentes de código, y la Vercel CLI, para humanos (y agentes headless sin acceso a MCP).
Las 4 herramientas MCP que de verdad vas a usar
La superficie MCP es pequeña a propósito — cuatro herramientas que mapean directo a un flujo de debug:
| Herramienta | Para qué sirve |
|---|---|
list_agent_run_projects | Encuentra proyectos de un team con actividad de Agent Runs |
list_agent_runs | Lista ejecuciones recientes de un proyecto |
get_agent_run | Inspecciona metadata, eventos de ciclo de vida, uso y datos de subagente |
get_agent_run_trace | Trae el trace completo: turnos, mensajes, reasoning, tool calls, tokens e I/O de tools |
Instala el servidor MCP en una línea:
# Registra el servidor MCP de Vercel en tu agente de código
npx add-mcp https://mcp.vercel.com
Ya registrado, le puedes preguntar a tu agente en lenguaje natural:
> Muéstrame los últimos Agent Runs de producción de mi proyecto
> Actualiza las skills con base en las ejecuciones recientes
El segundo prompt es el interesante. Como get_agent_run_trace devuelve reasoning estructurado e I/O de tools, un agente puede leer sus propios fallos y proponer cambios en prompts o schemas de tools. Es el loop de feedback que la mayoría de los equipos todavía arma a mano con harness de eval casero.
CLI: los mismos datos, sin MCP de por medio
No todos los entornos hablan MCP — runners de CI, cron jobs o un bash pelón. La Vercel CLI espeja las herramientas MCP casi 1:1:
# Actualiza a la CLI más reciente
npm i -g vercel@latest
# Descubre proyectos con actividad de Agent Runs
vercel agent-runs projects
# Lista ejecuciones recientes
vercel agent-runs list
# Inspecciona metadata y ciclo de vida de un run
vercel agent-runs inspect <run-id>
# Trae el trace completo
vercel agent-runs trace <run-id>
Dos detalles de diseño que vale la pena resaltar:
- Todos los subcomandos soportan
--json— salida legible por máquina para scripts y agentes sin MCP. - Los traces se renderizan como markdown cuando los pipeas — así que
vercel agent-runs trace <id> | lesste da un transcript legible en vez de JSON crudo.
Ese último es silenciosamente importante. Significa que un agente corriendo en un contenedor sin cliente MCP puede simplemente llamar a la CLI, leer su propio trace y autocorregirse.
Límites y cuidados
- Solo eve (por ahora). Los traces se auto-ingieren para agentes eve en Vercel. Si corres LangGraph, CrewAI o un loop casero, vas a tener que emitir spans compatibles por tu cuenta — la doc no promete un camino genérico de ingesta.
- Superficie de lock-in. Los Agent Runs viven en el dashboard y el MCP de Vercel. Exportar traces crudos a tu stack de observabilidad (Datadog, Honeycomb) no es el flujo principal aquí.
- Ver costo ≠ controlar costo. Ves el uso por run, pero no hay enforcement de budget incluido en este release.
- El reasoning depende del modelo. Si tu modelo no emite tokens de reasoning,
get_agent_run_tracete muestra turnos y tool calls, pero la sección de reasoning viene flaca.
Si ya andas pensando en fronteras de autorización para APIs disparadas por agentes, combínalo con los patrones de nuestro deep dive en autorización fine-grained de APIs.
Siguientes pasos
- Arranca desde un template. Vercel tiene starters de eve — elige uno, despliega, y los Agent Runs empiezan a aparecer minutos después de la primera sesión.
- Conecta el MCP a tu agente de código. El one-liner
npx add-mcpes el camino más rápido. Pídele que resuma los últimos 10 runs fallidos y los agrupe por tool call. - Arma un loop de auto-mejora. Haz que tu agente lea el
get_agent_run_tracede sus propios fallos recientes y proponga diffs en prompts o schemas. Revisas, haces merge, redeployas. - Ojo con la portabilidad. Si multi-cloud u observabilidad self-hosted te importa, trata los Agent Runs como una capa de conveniencia encima de tu backend de tracing principal, no como reemplazo.
Para equipos que ya usan ejecución sandboxed para código de agente, esto encaja perfecto junto al GA de Cloudflare Sandboxes — uno te da el runtime, el otro te da el recibo.
Lectura complementaria: el changelog oficial de Agent Runs de Vercel y la doc del framework eve en GitHub son los dos links que conviene guardar antes de subir tu próximo agente.