# 30% of Deployments Are Agent-Initiated. Is Your Platform Ready? > Source: > Published: 2026-07-17 10:11:25+00:00 Your deployment pipeline was not designed for this. Tom Occhino from Vercel [published something last week](https://vercel.com/blog/agentic-infrastructure) that I keep coming back to: 30% of deployments on Vercel are now agent-initiated. Six months ago that number was effectively zero. Claude Code alone accounts for 75% of those. You can call that a trend if you want. I think it already happened, and most platform teams are operating as if it didn’t. I am driven by experience here. I spent years building and operating internal platforms, and the one thing I learned is that platforms fail at the edges, not in the middle. The happy path always works. It’s the unexpected traffic shape that breaks things. An LLM initiating a deployment is a very different traffic shape than a human clicking “deploy” in a dashboard. The timing of this is not accidental. In the same week, Cloudflare shipped a [new unified CLI](https://blog.cloudflare.com/cf-cli-local-explorer/) that covers roughly 3,000 API operations across their entire surface. The interesting design decision buried in that announcement is the Local Explorer: a local REST API that deliberately mirrors the shape of the remote API. Local equals remote, by design. They are not building a developer tool. They are building something an agent can call reliably, in a loop, without surprises. DHH did the same thing with [Basecamp becoming agent-accessible](https://world.hey.com/dhh/basecamp-becomes-agent-accessible-3ae6b949). His framing is sharper than the headline suggests. Basecamp had a full API for years. Almost nobody used it. His argument is that the barrier was never capability — it was friction. Agents will use APIs that humans found too annoying to integrate. Coming from someone who shipped zero AI features because nothing felt worth it yet, this carries more weight than your typical AI endorsement. Three major platforms, same week, all moving toward the same thing: make yourself callable by a machine, not just a human. That is not a coincidence. That is a platform design requirement that just became visible. Will Larson wrote something that reframed how I think about what these agents are actually doing. In [Agents as scaffolding](https://lethain.com/agents-as-scaffolding/), he argues that agents work best when the shape of the work is known in advance. Not general-purpose autonomous systems — scaffolding for recurring tasks. His concrete example is security vulnerability patching: structured enough that an agent can own it end to end. The task has a known input, known success criteria, and a known exit path. Agents work best when the shape of the work is known in advance. This is the thing that breaks most internal platforms when agents start using them. Platforms are built around human judgment filling the gaps. The operator reads the error message and decides what to do. The agent cannot do that. If your deployment process requires a human to notice a Terraform plan looks wrong and abort it, you do not have a deployment pipeline — you have a deployment suggestion. Immutable deployments and preview environments stop being nice-to-haves. They become prerequisites. The agent needs to be able to act, observe the result, and act again, without a human in the loop catching edge cases. If the loop breaks because a manual step exists somewhere in the middle, the agent stops. Or worse, it does something you did not expect. The SRE question nobody is asking yet: what does observability look like when your traffic source is an LLM? I still remember the feeling when I first had to trace a failure through a system where I had no idea what initiated the request. At the time it was a misconfigured cron job. The debugging experience was the same kind of disorientation I expect teams are about to hit when agent-initiated traffic starts appearing in their dashboards with no obvious fingerprint. Agents will not tell your monitoring system they are agents unless you build for that. They will call your API, pass reasonable-looking headers, and if they hit an error, they will retry. Your on-call engineer will see a spike in 4xx errors at 2am and have no idea whether it is a misconfigured agent, a broken LLM tool definition, or an actual production incident. Those are three very different problems with three very different fixes. You need agent identity in your observability stack. Not as a nice label in Datadog. As a first-class concept that lets you answer: which agent, which task, which model version, and what prompt context initiated this request. Without that, you are debugging blind. LLMs will not fix that. Structured traces will. Larson also wrote a companion piece called “The agentic passive voice” — the idea that “Claude made a mistake” is passive voice because you are the actor, not the model. The agent works for you. The deployment happened under your platform, on your infrastructure. The incident is yours. Your platform was probably not ready six months ago when this started. The question is whether you are still waiting to find out. Practical lessons on shipping software, straight to your inbox. No fluff.