Vercel Stopped Selling Agents and Became One

For two years the agent economy has been described in vendor terms. Someone builds a framework. Someone hosts a runtime. Someone sells you orchestration. The customer is always the endpoint of the sentence.

Qu's framing breaks that grammar. Vercel built eve, its own agent framework, plus MCP libraries and skills.sh, and the payoff he describes is not a SKU. It is internal transformation: the company is becoming an agent and learning what that means from the inside.

That distinction is the whole story. Selling a tool tells you the vendor believes agents are marketable. Restructuring your own operations around them tells you the vendor believes agents are load-bearing. The second claim is far more expensive to make, because if it is wrong, the vendor pays first.

This is a second-order signal. First-order signals are demos, benchmarks, launch posts, the things designed to be seen. Second-order signals are the choices a company makes about its own guts when nobody is buying. When a platform reorganizes internal engineering around autonomous software, it is betting its own reliability, not yours.

The pattern resembles the classic tell in any technology transition: the moment the toolmaker starts eating its own tools for the parts of the business that actually matter, the category has moved from optional to structural. Vercel appears to be at that moment. The rest of this piece treats it as one and asks what follows.

Map it. On a Wardley evolution axis, technologies drift from genesis (novel, uncertain, hand-built) toward commodity (standardized, boring, bought by the unit). Agents have been sitting in the custom-built band: every company assembling its own harness, its own prompts, its own glue.

Qu's account of Vercel building eve, MCP libraries, and skills.sh is a company that built its own agent plumbing because there was nothing off-the-shelf reliable enough to run itself on. That is genesis-band behavior. You only hand-build the thing when you cannot yet buy the thing.

But the direction of travel matters more than the current position. The moment a platform company reorganizes internally around a component, that component is being pushed up the evolution curve by the most demanding possible customer: the vendor's own operations. Internal use at scale is how custom-built becomes product becomes commodity.

This connects to a live argument in the field. At the AI Engineer World's Fair, a panel debated whether autonomous software factories are viable now or whether the engineering discipline is lagging the ambition. The moderator's opening question was blunt: is there a delta between the hype behind loops and what actually works in practice?

Vercel turning itself into an agent is a data point in that debate, and a heavier one than a conference demo. It is a company saying the delta is small enough to run production on. Whether that holds is the open question. But the evolution has visibly started, and the direction is one-way.

Apply the Harness Hypothesis: the value in AI is not the model, it is the harness that connects the model to the world. Every component Qu describes is harness, not model.

eve is a framework for building agents. MCP libraries connect agents to tools and data. skills.sh packages capability. None of that is a frontier model. All of it is the connective tissue that turns a model from a chat window into something that can act inside a company.

That is the tell. Vercel did not train a model to become an agent. It built the harness that lets existing models operate as one inside its own walls. The company is betting that the durable value, and the durable control, lives in the harness layer it owns, not in the model layer it rents.

There is a competitive logic here worth naming. Commoditize your complement: a firm tries to commoditize the layer next to its own so that its own layer keeps the margin. If the model is a rented commodity, the harness is where a platform retains leverage. Building your own harness and running your own operations on it is the strongest possible version of that move.

The practical reading for you: when you evaluate any vendor's agent story, ask what they own. A vendor that owns only prompts on top of someone else's model owns very little. A vendor building and running its own harness, the way Qu describes, is making a structural bet. Those are the ones whose agent claims deserve weight.

Now the security desk earns its keep. The Trust Boundary Model says: find every place data crosses from one trust level to another, because those crossings are where you inspect and enforce.

When a vendor sells you an agent, the trust boundary is clear. It sits at your edge. The agent is a thing you deploy, sandbox, permission, and watch. You own the decision about how much autonomy to grant and where to draw the line.

When the vendor becomes an agent, a new boundary appears inside the vendor, and you cannot see it. Vercel's internal engineering now runs partly on autonomous software. The decisions that agent makes about deployments, configuration, and infrastructure sit upstream of every customer, behind a boundary you have no visibility into.

This is not a criticism of Vercel specifically. It is a structural consequence of the inward turn, and it applies to every platform that follows. Your attack surface now includes the vendor's internal agents, their permissions, and their failure modes, none of which appear in a status page.

Run Attack Surface Analysis on the new arrangement and the exposure is obvious once named: an autonomous system with production access inside your provider, operating on prompts and tools you never see. If it is compromised, misconfigured, or simply confidently wrong, the blast radius is the vendor's customer base. The honest state of the practice, evidenced by the live loops debate over whether autonomous factories actually work, is that this boundary is not yet well mapped. Watch for vendors to start disclosing where their internal agents operate. Right now, almost none do.

The Autonomy Spectrum runs from copilot (suggests, human decides) to full autonomy (acts, human reviews later, or not at all). Most agent failures come from deploying at the wrong point on that spectrum for the task at hand.

A company reorganizing its own operations around agents is, by definition, pushing toward the autonomous end for at least some internal work. You do not describe yourself as "turning into an agent" if a human still approves every action. The phrase implies delegation, not suggestion.

That is the highest-stakes region of the spectrum, and the field knows it is fragile. The same World's Fair debate that asked whether loops work in practice is really an argument about how far right on the autonomy spectrum you can safely deploy today. The pro-loop camp says far. The skeptics say the discipline lags the ambition.

There is a countervailing discipline worth borrowing. Simon Willison, relaying Geoffrey Litt at the same event, captured the "understand to participate" principle: as agents build larger and more sophisticated changes, you accumulate cognitive debt when your understanding drifts from how the system actually works. You need to understand the code to a depth that lets you keep participating.

Apply that to a company running on agents and the risk is organizational, not just personal. If the humans at a platform lose the depth to participate in what their internal agents are doing, the autonomy has outrun the controllability. That is the Capability vs. Controllability Frontier in operational form: the more you let the agent do, the harder it is to stay in a position to correct it. The inward turn is a bet that a company can stay on the right side of that frontier. Nobody has proven you can at scale yet.

You do not write frameworks. You configure an agent and hand it work. So why does a platform's internal reorganization matter to you?

Because it resets the question you should be asking. The relevant question is no longer "can an agent do this task?" The demos answered that. The question is now "what does it look like when a real organization, with real obligations, restructures around one, and where does it break?" Vercel is running that experiment in public, and Qu's interview is the field report.

Concretely, three things follow.

• Vendor due diligence changes. When you pick a platform, you are now inheriting its internal agent decisions. Ask which of a vendor's operations run on autonomous software, and what oversight sits on top. Most cannot answer yet. The ones who can are the ones worth trusting.
• The harness is the moat, so track who owns theirs. A vendor building and running its own harness, the way Qu describes eve and skills.sh, has a structural position. A vendor that is only reselling someone else's does not. That distinction predicts who survives the next round of commoditization.
• Your own autonomy decision just got a reference case. When you decide how far to trust your own agent, you now have a serious company's operational bet to reason against, plus the live disagreement about whether that bet is early.

The takeaway is not "trust agents more" or "trust them less." It is that the category crossed a line. When platforms start running themselves on agents, the choice you face is no longer theoretical. Map the boundaries before you delegate. Watch who becomes an agent next, and ask them what broke.