Vercel Agent Runs make AI coding work an observable execution record

Tech

When AI agents edit code, open pull requests, inspect deployments, and summarize incidents, the hard question is no longer just what they did. It is what a team can reconstruct later. Human engineering work leaves commits, CI logs, review comments, and deployment events. Agent work needs the same evidence trail or it creates an operations gap behind a productivity gain.

Workflow diagram showing AI agent work recorded as Agent Runs traces, queried through Vercel MCP and CLI, then used for review, cost, logs, and incident response
Agent Runs shift agent work from “good answer” to replayable operating evidence.

What happened

On July 3, 2026, Vercel announced Agent Runs support in the Vercel MCP server and Vercel CLI. The changelog lists four MCP tools: list_agent_runs, get_agent_run_details, search_agent_run_traces, and get_agent_run_summary. The CLI now exposes corresponding commands: vercel agent list, vercel agent inspect, vercel agent search, and vercel agent summary.

Agent Runs are Vercel’s observability view for agent execution. The docs describe automatic ingestion for eve-based agents without extra instrumentation, and the UI includes run status, start time, duration, model, token usage, trace timeline, logs, reasoning steps, and errors.

The important shift is not the dashboard itself. It is the access surface. Once the same records are available through MCP and CLI, other agents can query prior runs, CI scripts can attach summaries to failures, platform teams can search traces from the terminal, and incident workflows can preserve evidence without relying on screenshots.

Why this matters

The first hard problem in agent adoption is not whether an agent can produce a useful answer. In real teams, the bigger questions are who authorized the work, which files and tools were used, which model saw which context, what failed, and where a human can safely resume. Agent Runs are closer to an operations surface than a feature demo.

Vercel’s docs describe traces, status, duration, token usage, logs, reasoning steps, and errors. Those fields are not cosmetic. They are the minimum clues needed for incident analysis, cost allocation, review prioritization, and audit of sensitive context. If a pull request looks wrong, the diff is only one artifact. The prompt, tool calls, model, error recovery, and deployment context matter too.

MCP and CLI access also split the audience correctly. MCP is useful for structured agent-to-tool access from IDEs, agents, and internal platforms. CLI is useful for humans, shell scripts, and incident workflows. If observability is trapped inside a human-only dashboard, it is harder to operationalize.

Community signal

Developer discussion around agentic coding repeatedly comes back to review and accountability. Public threads on Hacker News are not product evidence, but they do show practitioners asking what reviewers should trust when automation changes real code.

Another recurring debate is CLI versus MCP. Some developers like the CLI because it fits the Unix surface that both humans and agents already understand. Others prefer MCP because structured protocol calls are easier for agent-to-tool integration. The useful reading is not that one surface wins. It is that teams increasingly need both.

That is why this release should be read as an operations update. Agent runs can now become the same piece of evidence across a dashboard, an MCP tool call, and a terminal command. That makes it easier to build review, cost, and incident workflows around agents.

Engineering and operations impact

The first impact is code review. AI-generated pull requests should not be reviewed from the diff alone. Reviewers need the task source, context, tool calls, failed attempts, token usage, logs, and tests. With MCP and CLI access, a PR template or review bot can attach a relevant run summary.

The second impact is incident response. If an agent helps investigate a deployment failure or suggests a rollback path, that session is part of the incident record. Teams should be able to find which logs were inspected, which hypothesis was formed, which command was proposed, and what the outcome was. Trace search and JSON-capable CLI commands make that easier to include in timelines.

The third impact is cost and capacity management. Run-level token usage lets teams move beyond “we used agents a lot” toward “this class of work is expensive.” Test failure diagnosis, documentation generation, large refactors, and log analysis have different cost shapes. Cost should be observed at the run level, not only at the provider bill level.

The fourth impact is privacy disclosure. Vercel documents that Agent Runs may capture prompts, reasoning traces, token usage, tool calls, logs, outputs, errors, generated code, diffs, repository context, deployment identifiers, and metadata. That is useful, but it also requires governance. Teams should know what can be retained in traces.

A practical checklist

1. Treat important agent runs as reviewable artifacts. Link the run or summary from meaningful pull requests, deployments, and incidents.

2. Separate MCP and CLI access. Human terminal lookup, agent self-lookup, and CI summary generation need different permissions and audit expectations.

3. Use CLI JSON output for internal reporting and incident bots. Do not make humans and automation depend on different sources of truth.

4. Treat token usage as both cost and complexity signal. A costly run is not always bad, but repeated expensive runs without explanation are an operations smell.

5. Tell teams what traces may contain. Repository context, logs, generated diffs, and deployment identifiers should appear in onboarding and governance docs.

6. Preserve the chain: run record, diff, tests, review decision. Automation that cannot be reconstructed later is not production-grade automation.

7. Start small: summarize failed deployments, list recent agent runs for a repo, and search long-running traces before wiring agents into critical paths.

Risks and counterarguments

The first risk is observability theater. A trace does not prove the agent was right. It is evidence for judgment, not the approval itself. Reviewers still need original diffs, test output, deployment status, and product context.

The second risk is data exposure. Observability becomes more useful as it captures more context, but that can include sensitive repository context and logs. Teams should verify log hygiene and redaction before storing production diagnostics in agent traces.

A fair counterargument is that this is too much process for small teams. But small teams also rely heavily on memory. If an agent-created change needs to be explained the next day, a run summary, PR, and test result are a lightweight place to start.

Agent Runs Operating Checklist

• 1. Treat important agent runs as reviewable artifacts. Link the run or summary from meaningful pull requests, deployments, and incidents.

Bottom line

Agent Runs support in MCP and CLI is not just another agent feature. It turns agent work into searchable, summarizable, automation-friendly operating evidence. The question for teams is no longer only whether the agent can write useful code. It is whether the work can be reviewed, explained, costed, and replayed when something goes wrong.

Sources

다른 글