Why Agent Observability Just Got Serious
Shipping an AI agent without observability is like deploying a microservice with no logs. You see the output, but you have no idea why the model called that tool, why it burned 40k tokens on a single turn, or where the subagent handoff went sideways.
Vercel's new Agent Runs feature closes that gap for eve-based agents. When you deploy an eve agent to Vercel, traces are ingested automatically — no SDK wiring, no OpenTelemetry collector to stand up. Every session becomes a queryable Agent Run with reasoning, tool calls, and token usage attached.
According to the official changelog, this is now surfaced through two paths: the Vercel MCP for coding agents, and the Vercel CLI for humans (and headless agents without MCP access).
The Four MCP Tools You Actually Need
The MCP surface is intentionally small — four tools that map cleanly to a debugging workflow:
| Tool | Purpose |
|---|---|
list_agent_run_projects | Find projects in a team that have Agent Run activity |
list_agent_runs | List recent runs for a specific project |
get_agent_run | Inspect metadata, lifecycle events, usage, and subagent data |
get_agent_run_trace | Pull the full trace: turns, messages, reasoning, tool calls, token usage, tool I/O |
Install the MCP server in one line:
# Register the Vercel MCP server with your coding agent
npx add-mcp https://mcp.vercel.com
Once registered, you can prompt your coding agent in natural language:
> Show me the latest production Agent Runs for my project
> Update skills based on recent runs
The second prompt is the interesting one. Because get_agent_run_trace returns structured reasoning and tool I/O, an agent can read its own failures and propose prompt or tool-schema updates. That's a feedback loop most teams are still hand-rolling with custom eval harnesses.
CLI: Same Data, Zero MCP Required
Not every environment can speak MCP — CI runners, cron jobs, or a bare bash session. The Vercel CLI mirrors the MCP tools almost 1:1:
# Upgrade to the latest CLI
npm i -g vercel@latest
# Discover projects with Agent Run activity
vercel agent-runs projects
# List recent runs
vercel agent-runs list
# Inspect a single run's metadata and lifecycle
vercel agent-runs inspect <run-id>
# Pull the full trace
vercel agent-runs trace <run-id>
Two design details worth calling out:
- Every subcommand supports
--json— machine-readable output for scripts and non-MCP agents. - Traces render as markdown when piped — so
vercel agent-runs trace <id> | lessgives you a readable transcript instead of raw JSON noise.
That last one is quietly important. It means a coding agent running in a container with no MCP client can literally shell out to the CLI, read its own trace, and self-correct.
Caveats and Limits
- eve-only (for now). Traces are auto-ingested for eve agents deployed on Vercel. If you're running LangGraph, CrewAI, or a homegrown loop, you'll need to emit compatible spans yourself — the docs don't promise a generic ingestion path.
- Vendor lock-in surface. Agent Runs live inside Vercel's dashboard and MCP. Exporting raw traces to your own observability stack (Datadog, Honeycomb) isn't the primary workflow here.
- Token cost visibility ≠ token cost control. You can see usage per run, but there's no built-in budget enforcement in this release.
- Reasoning traces are model-dependent. If your model doesn't emit reasoning tokens,
get_agent_run_tracewill show turns and tool calls, but the reasoning section will be thin.
If you're already thinking about authorization boundaries for agent-triggered APIs, it pairs well with the patterns in our fine-grained API authorization deep dive.
What to Do Next
- Start from a template. Vercel ships eve starter templates — pick one, deploy, and you'll have Agent Runs populating within minutes of the first session.
- Wire the MCP into your coding agent. The
npx add-mcpone-liner is the fastest path. Ask it to summarize the last 10 failed runs and cluster them by tool call. - Build a self-improvement loop. Have your agent read
get_agent_run_traceoutput for its own recent failures and propose diffs to prompts or tool schemas. Review, merge, redeploy. - Keep an eye on portability. If multi-cloud or self-hosted observability matters to you, treat Agent Runs as a convenience layer over your primary tracing backend, not a replacement.
For teams already using sandboxed execution for agent code, this slots in nicely alongside the Cloudflare Sandboxes GA release — one gives you the runtime, the other gives you the receipts.
Further reading: Vercel's official Agent Runs changelog and the eve framework docs on GitHub are the two sources to bookmark before you ship your next agent.