Your PaaS Thought One Developer Meant One Deploy Queue. Then the Agent Fleet Showed Up.

On February 24, 2026, Cursor gave its cloud agents their own computers: every agent runs in an isolated virtual machine with a full development environment, builds the software, clicks through the UI in a browser to test it, records video proof, and opens a merge-ready pull request. Two months later, the /multitask command in Cursor 3.2 started fanning a single developer's queue out to parallel async subagents. And the company's own dogfood number is the one to stare at: 30 to 35% of the pull requests Cursor merges internally are now opened by agents working autonomously in cloud VMs, according to CEO Michael Truell's February post. The committer on your next deploy pipeline is not always a person anymore. Sometimes it is a fleet supervised by one person.

That reframes a quiet assumption most deploy pipelines were built on: one developer produces roughly one stream of pushes, so a serial build queue and a preview environment per PR will do. An agent fleet breaks the arrival-rate side of that math while changing nothing about the service-rate side. This post works the burst math with real quota numbers, names the four pipeline stages that break under it, and lists the fixes teams already use — before mapping each one onto the self-hosted shape.

First, the premise box, because the details matter and some commonly repeated ones do not check out. What the public record supports: Cursor's Cloud Agents launched February 24, 2026 with per-agent isolated VMs and computer use; Bugbot graduated from beta the same month and its autofix spawns cloud agents onto pull requests, with over 35% of proposed fixes merged without modification; Cursor 3.2 (April 2026) added parallel /multitask subagents; agents are drivable from the editor, web, mobile, Slack, and GitHub; and in August 2026 Cursor launched Origin, a code host explicitly designed for agent fleets, on the argument that a forge built for humans assumes every PR represents human intent. The industry-wide backdrop: GitHub's Octoverse 2025 counted 43.2 million pull requests merged per month, up 23% year over year, with nearly a billion commits pushed in 2025 — and the Copilot coding agent alone authored over a million PRs between May and September 2025. Exact per-product queue depths (how many agents one developer can run at once) vary by vendor and tier, so the math below uses a range, not a single vendor's limit.

So here is the core deliverable up front: the burst table. Take a realistic supervised fleet producing 3, 8, or 20 concurrently open PRs, multiply by roughly 1.5 pushes per PR (initial push plus review updates — the ratio one 2026 Vercel cost analysis measured in practice), and compare the resulting preview builds against three pipeline shapes:

Two things to notice. First, the Hobby column is not a strawman — it is the shape a huge number of side projects and early teams actually run, and the failure mode is documented: teams already burn entire 100-deploy daily quotas on bot traffic alone, with ten open Renovate PRs spending the account's whole budget before human code gets a look. Agent fleets are Renovate with ambition. Second, the paid column does not exactly fail — it converts the burst into money and latency instead of errors, which is precisely the line item to watch: one cost analysis put a 20-PR-per-day habit at roughly $231 per month in build minutes alone, before production builds, QA bandwidth, or function invocations. The burst always lands somewhere. The only question is which budget absorbs it.

Failure mode 1: the build queue was sized for humans​

Every hosted pipeline has a concurrency number, and most teams have never read theirs. On Vercel's Hobby tier it is one concurrent build, with 32 builds per rolling hour and 100 deployments per rolling day, account-wide rather than per project. Paid team plans move to on-demand concurrency with a documented 12-concurrent-build ceiling per team. Those numbers were chosen when the expected load was a developer pushing, waiting for green, and pushing again. Twenty agent branches pushing within minutes of each other turn that queue from a formality into the system's actual throughput limit — and because the quota is account-wide, one developer's fleet can starve every other project on the team, including production deploys waiting behind thirty previews.

The fixes are queue policy, not bigger machines:

• Cancel superseded builds. When an agent pushes three commits to the same branch in ten minutes, only the tip needs a preview. Every hosted provider supports cancelling outdated builds, but many teams never enable it because human push cadence never made the waste visible.
• Priority lanes. Production and main builds must preempt preview builds — or at minimum, preview builds must never block them.
• Skip rules for agent draft branches. The ignoreCommand mechanism teams already use to stop bot branches from spending deploys (exit 0 means "don't build this push") generalizes directly to agent work-in-progress branches. Build on PR-ready, not on every intermediate commit.
• Per-branch build budgets with alerts, so the first morning a fleet opens twenty PRs pages someone before the invoice does.

Failure mode 2: preview environments fan out without a ceiling​

One PR, one preview URL is the bargain every frontend PaaS sells — Vercel mints a preview deployment per pull request automatically, with branch-specific environment overrides. It works beautifully at human scale. At fleet scale it is an unbounded fan-out: N concurrent agent PRs means N concurrent preview stacks, each with compute, bandwidth, serverless invocations, and review attention attached. The teams running preview environments on Kubernetes already learned the shape of the answer, and it is always the same four controls. A global cap on concurrent previews (three to six per app is the common range in the wild), with new PRs queueing or replacing the oldest. Label-gated previews: only PRs carrying an explicit deploy/preview label get an environment, so agent draft spam never mints infrastructure. Automatic teardown: closing or merging the PR garbage-collects every preview resource — namespace, DNS record, certificate, data volume — because the Let's Encrypt rate limit and the cloud bill both punish orphans. Per-preview resource quotas: CPU, memory, and pod-count ceilings per environment so one agent's load test cannot eat the pool.

Note what each control is really doing: converting an open-loop fan-out into a closed-loop scheduler with backpressure. That is the entire conceptual shift the fleet forces. Human-scale previews are fire-and-forget; fleet-scale previews are a scheduling problem with admission control, and pipelines that lack admission control will rediscover why schedulers have it.

Failure mode 3: every preview needs its own data plane​

Compute fan-out is the visible problem; data fan-out is the one that pages you. A preview that shares the staging database works when one human clicks through one preview at a time. Twenty agent previews running migrations, seeding fixtures, and asserting against the same shared staging schema produce the classics: migration races, fixture collisions, rate-limit dominoes (one team's shared fixtures hit a 1-per-day creation quota and every preview after the first 429s), and the worst variant — an agent's preview writing into data a human's QA session is reading. The rule that falls out is simple to state and annoying to build: each preview gets an isolated data plane and scoped secrets.

Concretely: per-preview database branches or throwaway seeded instances rather than one shared staging schema; preview-scoped credentials in the branch-specific environment slot, never production secrets copied down; migration locks or serialized migration runners so concurrent agent branches cannot interleave schema changes; and seed data designed for parallelism — deterministic per-branch prefixes instead of global unique constraints that turn the twentieth preview into a conflict. This is also where preview costs hide their second half: the compute preview is metered in build minutes, but the data preview is metered in managed-database spend, and neither dashboard shows you the combined number without effort.

Failure mode 4: review becomes the pipeline's narrowest stage​

Suppose builds, previews, and data all scale. The PRs still need human approval, and the trust data says humans are getting slower to give it, not faster: Stack Overflow's 2025 survey found trust in AI-tool accuracy fell to 33% from 43% a year earlier, even as Google's 2025 DORA report found 90% of developers using AI at work. More machine-written code meeting less machine-trusting reviewers is a queue that grows from both ends.

Cursor's own answer is instructive: Bugbot reviews every PR and autofixes what it finds, which means part of the fleet now reviews the rest of the fleet, with humans sampling the output. That can work — the 35%-merged-unmodified figure says it often does. But an autofix loop with no guardrails is a livelock machine: agent A writes code, agent B flags it, agent C rewrites it, agent A re-pushes, and your pipeline bills every lap.

The triage rules that keep the merge stage moving:

• CI must pass before any human looks. Algorithmic review first, eyeballs only on green builds — which also keeps autofix churn off human plates.
• Blast-radius labels on every agent PR (docs-only, test-only, migration-included, public-API change) so reviewers spend attention proportional to risk instead of FIFO.
• Autofix guardrails. Cap fixup rounds per PR, require a human checkpoint before the third rewrite of the same hunk, and never let a review agent approve its own sibling's output.
• A real merge queue rather than parallel merges with fingers crossed. At fleet push rates, the probability that two green PRs conflict semantically stops being a corner case.
• Record provenance as pipeline metadata. When a third of merged PRs are agent-authored, "who intended this change" — the supervising human, the prompting session, the model — must be attached at merge time, not reconstructed as archaeology after an incident.

Why this shape favors the fleet you own​

Map each failure mode onto a self-hosted Cluster-API fleet and notice how many answers are already primitives rather than features to buy. Build-queue serialization (mode 1) becomes horizontally scaled builders: build workers are just pods, so the fleet's arrival rate is answered with more workers up to a quota you set, and cancel-superseded is a controller policy, not a plan upgrade.

Preview fan-out (mode 2) is the native Kubernetes shape — a namespace per PR with ResourceQuotas, an HTTPRoute per preview hostname, a single controller enforcing the global cap, label gating, and garbage collection on PR close. Preview data (mode 3) is per-namespace database branches or ephemeral instances on the same nodes, with sealed, preview-scoped secrets — no managed-database line item multiplying by twenty. And merge triage (mode 4) runs where your policy engine already lives, with the full event history on infrastructure you can audit rather than inside a vendor's black box.

The deeper point is economic, and it is the same one the burst table makes: hosted pipelines convert fleet bursts into metered line items — build minutes, preview bandwidth, function invocations — while a fleet you own converts them into scheduling decisions against hardware you already pay for. The burst still has to be managed; admission control, caps, and garbage collection are mandatory in both worlds. But on owned hardware the failure mode for "twenty agents pushed at once" is "previews queue for ten minutes," not "the account's daily deploy quota is gone and production is waiting behind thirty previews."

The committer is a fleet now. Cursor's internal 35% is the present inside one AI-native company; Octoverse's 43.2 million monthly PRs are the industry-wide arrival curve. Pipelines designed around one developer's push cadence — serial builders, unbounded previews, shared staging data, FIFO human review — will absorb that curve as quota exhaustion, cost surprises, and review gridlock, in that order. The fix in every stage is the same idea wearing different clothes: backpressure. Cancel what is superseded, cap what fans out, isolate what shares state, and triage what needs eyes. Build those four, and the fleet reads as throughput. Skip them, and it reads as an incident.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Per-branch preview environments with caps and garbage collection are exactly the kind of admission control a self-hosted fleet does well. Star the repo on GitHub or deploy your first app today.