The shift from single-agent chats to parallel agent fleets

Early AI-assisted development meant one engineer talking to one agent about a local codebase. That model has given way to something larger: developers now direct fleets of agents working in the cloud, often across multiple branches at once. The tooling that surrounds this workflow—IDEs, terminals, review systems—was built for a serial process where one developer moves one ticket at a time.

Superset, founded by Kiet Ho, Satya Patel, and Avi Peltz (all former CTOs at YC-backed companies), positions itself as the IDE for this multi-agent era. It runs up to 10 coding agents in parallel, each in its own isolated workspace, letting developers coordinate teams of agents generating code across branches simultaneously.

That promise of parallelism places a hard requirement on the underlying platform: nothing can force work to wait. If any layer introduces latency, even briefly, the parallelism on top collapses into a serial queue.

"Vercel uptime isn't something we plan around. It's a given."

Kiet Ho Co-Founder and CEO

Why the platform matters as much as the product

The dependency on instant provisioning is invisible from the product surface, but it's decisive. Each agent thread needs its own environment, each branch needs a live URL, and each change needs a safe place to run. Without this, CI pipelines must be configured per branch, preview environments need manual management, and deploys back up behind one another. Twelve parallel workflows collapse into one queue, turning a minutes-long task into hours. The developer is back to waiting—the exact problem Superset exists to solve.

Six Next.js projects without a platform team

Vercel was the default from the start: all three founders had built on it previously. From day one, Superset ran six Next.js projects on the platform: the web app, marketing site, docs, and three supporting services. The team skipped platform engineering entirely.

Every branch a Superset developer or agent creates becomes a preview deployment automatically, often spinning up multiple services. Internally, that generates roughly 600 preview deployments per day, and no one waits on a deploy queue.

A single AI stack assembled from platform primitives

Superset's AI stack grew iteratively as features were added, with each piece pulled in to address a specific need.

Orchestration and model routing

Storage and compute

  • Vercel Blob stores artifacts from agents and users, removing object storage management.

  • Fluid compute scales underneath as agents fan out. Active CPU pricing charges only for actual compute, not for round-trip time spent waiting on model responses.

Operational controls

  • Cron Jobs keep parallel environments from accumulating.

  • BotID filters bots during traffic spikes without custom middleware.

As Superset expanded into new product areas, everything stayed on Vercel. There's no second cloud, no orchestration layer to maintain, and no platform team to hold it together. Each new surface area builds on the same primitives as the previous one.

Eating its own dog food

The strongest validation of Superset's approach is internal usage. GitHub issues flow into Superset and get split across parallel workspaces; Patel has tuned the setup to run up to a dozen instances concurrently. Multiple efforts proceed without anyone waiting on serial decisions. Compared to previous workflows, the team's commit graph looks exponential.

Weathering a Hacker News spike

During a Show HN launch, user counts tripled overnight. Superset absorbed the spike without mid-flight infrastructure provisioning.

The same principle applies to incidents. When a customer reports a bug, agents can spin up, write a fix, generate a preview, and merge the change in under thirty minutes. If the fix introduces a regression, rollbacks are instant, dropping the cost of a bad deploy to near zero.

"When you're using Vercel, it's almost no time to deploy."

Satya Patel Co-Founder and CTO

Scale metrics and what's ahead

Deployments run between 1,000 and 1,400 per week, with average build times around 30 seconds. That volume matters because it keeps the loop—writing code, previewing it, shipping it—short enough that velocity never stalls, even across dozens of parallel workstreams.

The trajectory is clear: a product built for parallelism, by a team that works in parallel, on infrastructure that doesn't force them back into a queue. Every new agent capability shipped to customers is stress-tested internally by engineers running a dozen instances at once. When that dozen becomes two dozen, the infrastructure underneath is expected to absorb it without a second thought.