Your first responder for production incidents
Vercel Agent now lives directly in your dashboard. What started as a tool for triaging alerts and reviewing pull requests has grown into an always-available investigator for your production environment, projects, and deployments. It operates under its own identity with read-only access by default, and you can reach it from the Dashboard, GitHub, or the CLI.
The value shows up most clearly in an incident. Consider a bad deploy that ships at 11pm and starts throwing 500s on your checkout endpoint. Before your on-call engineer even opens a laptop, Vercel Agent has already followed the errors back to the deploy that went out four minutes earlier. When the engineer logs in, they find a rollback plan ready for approval. With permission granted, the agent rolls back to the previous production deployment and starts drafting a pull request with the fix. The timeline from alert to mitigation: under three minutes.
You can also drive Vercel Agent directly. Hand it a task and it either answers your question or returns a fix for you to approve. It never takes action on its own in production. Typical uses include reviewing pull requests for hidden performance issues, tracing the source of a cost spike, fixing a broken build by adjusting config in a sandbox, and checking whether a feature flag rollout is safe by reading both code and live metrics.
Vercel Agent in your dashboard, ready to take questions about your projects.
Rethinking who gets permission — and how
An agent capable of fixing your application is also capable of breaking it. The safety question is straightforward: how do you let something touch production without handing it the keys to everything? Most agents on the market today answer by inheriting the full permissions of the user who invoked them. A confused prompt or a misbehaving sub-agent then carries the same blast radius as a human mistake. The trade-off has always been between read-only safety and standing access with real power.
Vercel Agent approaches the problem from three directions: its identity, its allowed actions, and the runtime for the code it writes.
A principal of its own: vercel-agent
Instead of acting as you, Vercel Agent runs as its own principal. That yields two concrete benefits. First, attribution: every action records who requested it, who approved it, and that the agent carried it out. Nothing the agent does is untraceable. Second, authority: a separate identity means it does not inherit your access automatically. It receives only what an approved plan grants — and never more than the person directing it already has.
Agent actions appear separately, attributed to both the agent and the approving user.
Plans as the unit of permission
Typical agent integrations start by handing out broad permissions up front. Vercel Agent inverts that model. It is read-only by default. To roll back a deployment, change a config, or purge a cache, it puts together a concrete plan and requests access scoped precisely to that plan. When you approve, the agent receives a short-lived capability covering only the named tasks, executes, and returns to read-only status.
Every call the agent makes is checked three ways: against the capability from the plan, the scope of the token, and your team's existing permissions. Those enforcement checks live in the platform itself, meaning they are not dependent on the model behaving correctly. This plan-to-permission model keeps privilege low by design. Even a worst-case failure confines the agent to the boundaries of the approved plan.
The agent proposes a plan and requests scoped access before it can act.
Generated code goes to the sandbox
Permission models cover what the agent is allowed to do, but they do not answer whether the code it writes will actually run. Vercel Agent executes its generated code inside Vercel Sandbox, an ephemeral Firecracker microVM isolated from your live systems and the host environment. The sandbox contains a real copy of your project, so the agent can test its changes against your actual build, tests, and linters. Only what passes gets surfaced to you. The agent can write and run code freely without ever being able to place something broken in front of you or into production.
Why the infrastructure has to hold
Agent reliability is bounded by two ceilings: what the model can do, and how much of that capability you are willing to let it exercise. As models improve, the first ceiling lifts and the second becomes the defining constraint. Trust is the bottleneck.
But a better model is still a non-deterministic system, which means its failures will be non-deterministic too. No safety story can rely on the agent being correct every time. The trust has to be in the surrounding system, and that system gets judged by what a failure actually costs you. Vercel has spent years driving that cost down with immutable deployments, where every deploy is preserved and any bad one is a single rollback away. That guardrail was not originally designed for autonomous agents, but it is precisely the safeguard one needs. When the foundation of the platform is itself the safety net, you can grant real autonomy without betting that the agent is always right — and human errors become easier to absorb as well.
What comes next
Vercel Agent today can investigate anomalies, open pull requests, and answer questions in production. On the roadmap are on-demand specialist delegations for tasks like deep security review across your codebase and design-level UX reviews of your frontend.
