Agentic software changes what the platform underneath has to do
Infrastructure has moved through distinct phases: hand-configured servers, cloud APIs, and then infrastructure derived from the application itself. The rise of LLMs and coding agents is forcing the next shift, and the velocity data makes the case concrete. Weekly deployments on Vercel have doubled in three months, with agents now initiating more than 30% of all deployments, up 1000% from six months ago. Claude Code drives 75% of those, with Lovable and v0 at 6% and Cursor at 1.5%.
This isn't just a faster version of the same workflow. Projects deployed by coding agents are 20 times more likely to call AI inference providers than human-initiated deployments. Agents are writing software that uses AI, and increasingly, agents are building other agents. When the final actor in the loop is a machine rather than a human, the operational model has to change. That means infrastructure designed for agentic software, which spans three distinct layers.
Infrastructure that coding agents can deploy to.
Infrastructure for building and running agents.
Infrastructure that is itself agentic.
Deployment surfaces without human gates
The operational friction between code and running system is the bottleneck for agentic engineering. A coding agent that produces a feature needs somewhere to run, test, and verify it, which in practice means a URL. If the path from commit to running system requires manual Terraform state or clicks in a console, the autonomous loop breaks. Agents need programmatic, deterministic deployment surfaces.
That changes the status of certain platform features. Immutable deployments, preview URLs on every commit, and instant rollbacks are no longer just developer experience conveniences; they are prerequisites for machine-driven development. Native agent access to the CLI, API, MCP servers, and git integration lets an agent generate code, open a PR, get a preview URL, verify the output, and ship to production without any human in the loop.
Runtime primitives for long-lived agent workloads
Classic serverless workloads suit short-lived requests, edge functions, and caching. Agent workloads have a different shape: long-lived execution, multi-step orchestration, model routing, cost controls, sandboxed code execution, and abuse resistance. The penalty for assembling that stack yourself is steep. Wasted requests burn inference dollars, a provider outage takes your agent offline, and untrusted code opens the door to prompt injection.
The platform approach unifies the required primitives in one place:
AI SDK provides a unified interface for AI-powered applications across frameworks and providers; AI SDK 6 adds an agent abstraction so an agent can be defined once and reused across interfaces and workflows.
Chat SDK exposes agents across dozens of chat apps and platforms from a single codebase.
AI Gateway gives teams a single endpoint for hundreds of models, with budgets, monitoring, routing, retries, and fallbacks.
Fluid compute targets the mixed latency, concurrency, and idle-wait profile of AI workloads.
Workflows and Queues let agents pause, resume, retry, maintain state, and offload background work.
Sandbox provides isolated execution environments for untrusted code.
Observability lets teams trace agent behavior and diagnose failures.
These building blocks give developers a complete stack for building and running agents. The deeper value lies in unifying them so code, model calls, and runtime behavior share one context. That shared context is the precondition for the third layer.
Infrastructure that responds to production
Traditional infrastructure is one-way: code goes in, logs come out, and a human reads the logs to fix the code. A unified platform with real-time visibility across every layer changes that equation. It gives agents the ability not just to monitor production, but to respond autonomously to it.
When a latency spike hits a critical route or a model provider drops requests, the platform can investigate the anomaly, query observability data, read logs, inspect source code, perform root-cause analysis, and review proposed fixes in isolated sandboxes. The system interprets developer intent, observes what actually ran, and acts on the difference between the two. That capability currently operates with human approval in the loop; over time, the platform will take on more of that operational burden, not by replacing developers, but because it has enough context to act on their behalf.
The trajectory of cloud computing has been the gradual removal of the human from the machine. The next step is infrastructure that expects software to write, ship, and heal itself, and that is built to act accordingly.
