Vercel recently published an overview of its Agent Stack, a collection of tools for model routing, durable workflows, sandboxed execution, system access, and user-facing integrations. The individual pieces are interesting, but what stood out to me was the shape of the stack as a whole.
The industry is starting to treat agents less like prompts wrapped in an API call and more like long-running production systems.
That shift matters because most of the difficult problems begin after the first successful demo. A useful agent needs to choose an appropriate model, keep state across several steps, recover when one of those steps fails, access external systems without receiving unlimited credentials, execute untrusted work safely, and leave enough evidence behind to explain what it did.
Those are infrastructure problems.
The model is only one dependency
Vercel starts with model access and routing. Its AI SDK provides a common interface across model providers, while AI Gateway handles routing, failover, cost, and usage through a single endpoint.
I have been moving in a similar direction in my own agent setup, although at a much smaller scale. I do not want every task sent to the most capable or expensive model. Repository exploration, planning, implementation, and review have different requirements. A small local model may be perfectly adequate for scanning a codebase, while a frontier model is better used to produce the implementation plan or resolve an ambiguous design decision.
The routing decision is therefore part of the system design. It affects cost, latency, privacy, failure handling, and the quality of the final result. Once several models are involved, the router also needs fallback behavior and enough telemetry to show which model handled each stage.
Treating model selection as configuration rather than application logic is an important boundary. Models will change more quickly than the workflows built around them.
Durable execution is where the demo becomes a service
The workflow layer is the part of Vercel's announcement that feels most familiar to anyone who has operated distributed systems. Long-running jobs need checkpoints, retries, persisted state, and a way to pause for a person or an external event. Restarting a thirty-minute workflow from the beginning because step twelve failed is expensive and sometimes unsafe.
The same concern shows up in my recurring automation. A scheduled agent job may read data, call a model, write an artifact, update another system, and send a notification. A scheduler can start that job, but scheduling alone does not define what happens after a partial failure.
Did the external write succeed before the process died? Is the retry idempotent? Which step should resume? How many attempts are acceptable? What output proves the run completed correctly?
These questions are familiar because they are the same questions we ask of deployment pipelines, batch systems, and control planes. The presence of a model does not remove the need for state machines and recovery behavior. It usually adds more non-determinism to manage.
The missing boundary is often ownership
Vercel packages its capabilities as a cloud platform. In my homelab and local development environment, the problem I have been working on is lower in the stack: how to package a recurring agent workflow so that its operational contract is visible in one place.
My current approach is a repo-managed agent-loops/ catalog. Each loop package owns its manifest, scripts, prompts, systemd units, model choices, secret key names, deployment destinations, and verification commands. The package can be reviewed without reverse-engineering scheduler rows and files scattered across several hosts.
The first version is intentionally masterless. The Git repository is the source of truth, deployment is local or SSH-based, and the target can be a laptop, Raspberry Pi, LXC, or cloud VM. Existing schedulers still execute the work. The package layer defines ownership and provides validation, dry-run, deployment, and verification around them.
That differs from Vercel's goal, but the underlying pressure is the same. Once agents perform recurring work, configuration and runtime state begin to drift unless the system makes ownership explicit.
Secure tool access cannot remain an afterthought
An agent becomes useful when it can act on other systems, which is also when the risk changes. Reading a repository, opening a pull request, querying a database, or posting a message requires credentials and authorization decisions that a local prototype can easily gloss over.
Vercel Connect addresses this with short-lived, scoped credentials tied to a task. That is the right direction. Long-lived tokens with broad permissions are a poor default for software that can choose and execute actions dynamically.
The same principle applies outside Vercel. An agent should receive the smallest capability needed for the current task, for the shortest practical period, with an audit trail connecting the user request to the resulting action. Secrets should not be embedded in prompts, package manifests, or generated scripts. Human approval should remain available for destructive or externally visible changes.
This is one area where the agent ecosystem is still uneven. Tool integrations are often presented as a list of things an agent can do, while permission scope, revocation, attribution, and auditability receive much less attention.
Portability is still a useful constraint
Vercel is building an integrated path for teams that want to deploy agents on its platform. There is real value in having routing, workflow durability, isolated compute, system access, and chat integrations designed to work together.
I am optimizing for a different environment. Some of my workflows should run on a MacBook. Others belong on a small Linux host in the homelab. A few may eventually run in Kubernetes or a cloud service. I want the package describing the work to remain useful even when the scheduler, runtime, or model provider changes.
That constraint pushes the design toward generic concepts: placement, schedule, runtime, files, model policy, secrets, deployment, and verification. Platform-specific behavior belongs in adapters rather than at the center of the package format.
There is a tradeoff. An integrated platform can offer stronger defaults and a smoother developer experience. A portable, masterless design requires more assembly and cannot assume a managed workflow engine or credential broker exists. For personal infrastructure and edge systems, I still prefer keeping the operational contract independent of a single control plane.
What I took from the Agent Stack
The announcement did not make me want to replace my current design with another agent framework. It clarified the layers that production agents are converging around:
- model access and routing
- durable workflow execution
- isolated runtime environments
- scoped connections to tools and data
- interfaces where people can interact with the agent
- deployment, observability, and auditability across the whole path
My own work is currently concentrated on the packaging, placement, deployment, and verification boundaries beneath those layers. Vercel is assembling a managed application platform above them. The two approaches overlap, but they are solving for different operating environments.
The broader signal is more important than either implementation. Agents are becoming production workloads, and the teams operating them will need the same discipline used for any other distributed system: explicit ownership, controlled deployments, bounded permissions, observable execution, and tested recovery behavior.
The model may be the most visible component. It is no longer the whole system.