What replaced Vercel’s chained data agent when the next step only saw a summary?

An agent on every desk, in a weaker model era

Andrew Qu’s story of Vercel’s data agent runs in that order. The chained version failed because the next agent saw only a summary and a short snippet, so it could not look back at the steps that got there. They replaced the chain with one agent that keeps its own steps, a single long call that could retry after an error. Early users still called that tool awful. Real questions fell outside the scenarios they had mapped, even though the builders thought it was passing about 30 percent of an eval set he never defines. The design he treats as the leap came after that failure: the warehouse’s semantic layer in a sandbox the agent could explore with file and shell tools. Eve is his proposal for declaring that later filesystem-and-skills pattern so the next builder does not restart from a raw prompt. The scores he attaches to the jump stay his.

He introduces himself as chief of software at Vercel, working across internal engineering, outside experiments, and new libraries and frameworks. That is his description of the job. He frames the company the same way: Vercel started by letting people ship websites and web apps without operating the infrastructure underneath, including a line about scaling to a million and back down to zero, and he says customers who used to want pages now want agents. Both lines are positioning, with no measured reliability or scale result beside them.

The AI SDK is his example of that ease. He says one shared model interface means a provider swap is about one line, against roughly 300 to 400 lines of provider-specific code. That line count is his contrast, with no SDK benchmark beside it. He also says the platform added model fallbacks, secure code execution, better pricing while a workload sits inactive and waits on a response, and durability and resumability. He names durability and resumability without defining them, and he gives no prices or idle-billing terms.

The experiment, he says, started about a year before the talk, in a period he calls Sonnet 4, when he considers the models less capable than the ones available as he speaks. He and Vercel’s chief technology officer, whom he does not name, borrowed a 1980 line he attributes to Bill Gates: a computer on every desk and in every home. Their version was an agent on every desk, past coding into design, product management, and other work. The Gates wording and the year are his retelling. He also says that, at the time of the bet, agents were used mainly for coding and technical work, with expansion just starting. “About a year ago” stays relative to the talk. The recording’s 14 September 2026 posting date is when the video went up.

• How We Solved Agent Building — Andrew Qu, at AI Engineer

The question that buried a lean data team

Qu says he asked marketing, sales, finance, and legal what they hated most about the job. The case he calls most compelling was the data team: lean, while Vercel’s customer, analytics, metrics, and sales data grew faster than the people who had to make it usable.

He spells the interruption in operational terms. A marketing or sales question about a customer or product made data science stop, write a query, analyze it, and come back with a recommendation. He says that badly hurt productivity, and the team did not want writing queries all day to be the work. He then worked with Vercel’s vice president of data, also unnamed, on another way to operate. That is the motive for D0. He gives no ticket counts, hours, or staffing audit.

Version one was a schema dump and a manual paste

The first test was a mega prompt. Qu asked for a dump of the Snowflake schema, the warehouse’s description of tables and columns, pasted that dump and a question into the system prompt, and, when the model returned SQL, copied the query and ran it himself. SQL is the language the warehouse executes.

He keeps the result modest, and every later success claim sits on top of this start. He says the models were not that good. The test only gave slight confidence that better surrounding context and guardrails might make them usable. He gives no warehouse size, no account of who was allowed to query, and no safety control around that paste test.

D0 chained the analyst loop, then lost the trace

Qu then maps what a person on that team does with a question. They take it in, explore the semantic layer and the join patterns, run the SQL, and try again if the query fails or costs too much. A semantic layer, in the way he uses it, is the set of entity descriptions and relationships an analyst consults before choosing tables. After a query works, they visualize, write, and review, sometimes as a retro.

He and the VP of data split that loop into chained agents, each with a narrow prompt and narrow tools. He introduces the data agent as D0 on this second version and says he will keep the name. His sequence runs from a question through a query agent, a planning agent, and an execution agent, then SQL and reporting. Those names overlap as he talks: he also describes the planning side passing an answer onward to “the planning agent,” and then to a SQL agent and reporting.

The concrete tool example is the planning agent. It could read entity YAML, a structured file describing an entity, and search schemas, and he says it used only those capabilities until it had an answer to hand on.

He treats the gain as qualitative. The loop could go from question to answer without someone pasting SQL back in. He states no accuracy rate. The wall, in his account, was the handoff. The next agent received only a summary and a short snippet, so it could not look back at how it got there. They concluded that one agent should hold the full context, manage its own memory, and reflect on the steps that led to the current point. That conclusion comes from using D0.

One long call could retry, and early users still hated it

The next design was one model call that switched among planning, building, executing, and reporting, and managed that state itself. He illustrates the call at about a 100-step maximum. The 100 is his picture of that call. He does not state it as a limit of Eve or of a named model.

What he highlights is recovery. After an execution error or a bad join, the same agent could explore or read again and work out what it had done wrong. They showed it only to a few trusted people. He calls the tool powerful and says they kept it away from the wrong people and off critical workloads. He does not define the access rule or those workloads.

The internal score and the reaction belong together. The builders thought the agent was passing about 30 percent of their evals, the test questions they had written. The first users said it was awful. Real questions fell outside the scenarios they had mapped, and mapping more of them by hand looked unscalable. The 30 percent figure has no defined eval set. It is their impression at the time, sitting next to that backlash.

The leap he names is a sandbox filesystem

Qu says Opus 4.5 arriving with Claude Code answered most of their questions far better than the hand-built agent. He calls that pair basically AGI compared with what they had before. The phrase is his hyperbole. He names no shared eval score for the head-to-head.

The unlock he draws is a filesystem and a small tool set: list file, read file, and bash, the shell command that runs programs in that environment, plus a few extra tools for the data agent. He says those are tools agents are already trained to use well, and that the model was left to explore instead of being handed a prescriptive menu. He does not describe Claude Code’s tool list or its training.

They rebuilt D0, the same data agent, in a sandbox, an isolated environment, loaded the whole semantic layer into it, and gave the agent bash, read, and write, plus a few Vercel-specific tools. He calls the move from one agent, to a Claude Code SDK style, to a filesystem agent the biggest leap. He also says “fine-tuned or purpose-built.” That reads as an agent shaped for their case. He gives no account of training a custom model.

At that design, he says the eval score roughly doubled. The baseline, the tasks, and the before-and-after pair are unspecified, so “doubled” is his summary of an internal score whose contents he never lists. The implementation, as he describes it, is a bash-tool helper on npm attached to a sandbox, with files the agent can read, write, and execute. He does not give a package name precise enough to identify. After that result he wrote a blog post he says was still live, and he says the week it ran it accounted for about 70 percent of vercel.com traffic. The share is his, for a week he does not date, and he gives neither the post’s title nor its address.

Repeated queries became a skills folder

A wider internal rollout, in his telling, drew thousands of queries a day across customer metrics, sales metrics, npm downloads, product lookup, and billing. Thousands a day is his volume claim. Many of those questions shared a shape: aggregation, lookup, or billing.

A recurring job takes recent queries and distills them into skills. A skill, as he uses the word, is saved context for a kind of question the agent has already worked through. He says they have about 100, from aggregations through lookups of data about specific people. His reason is that a new run otherwise begins with only the semantic layer and the system prompt, while a skill carries work already done. That is a design argument. He reports no token or latency saving, and he does not describe the job’s algorithm, who reviews a skill, or who may use one.

He points to a skills folder as the practical addition and says Vercel built a tool he calls Skillsh, the most popular way, in his words, to find agent skills and run them yourself. The popularity line is his. He gives Skillsh as the name, with no directory address and no install steps.

Eve is the convention layer he wants builders to start from

Colleagues kept forking D0 and rediscovering each improvement. Qu asks why a new builder should restart from a raw prompt or from first principles. That is the motive for a framework.

The analogy is Next.js, which he says Vercel built. In his explanation, files in the right conventions place pages, serverless functions, and caching without anyone wiring the infrastructure by hand: pages to a CDN, functions in their place, cache in the middle. He wants agents declared the same way. That is his account of why conventions help, and it is not a current architecture spec for Next.js.

The agent version he proposes is three folders: skills, tools, and channels. Channels, in this pitch, are the places people already talk to the agent. The framework is supposed to turn that declaration into an agent. He says Eve, which he calls the Next.js for agents, shipped about two weeks before the talk, including at a London event. From a sample template, he says, you add custom knowledge, tools, and familiar channels. The two weeks and the London event are relative to the talk.

His picture of an agent is a runtime plus channels. The open-source adapters he names are Postgres, OpenAI’s responses API, Docker, and other connectors. Those are the plugs he lists. On Vercel he maps durability to Workflows, secure execution to Sandbox, and short-lived connection tokens to Connect, which he says had just been released. He calls those tokens ODC tokens and does not expand the acronym. Connect’s launch and that token behavior stay his account.

• A runtime that needs durability, an isolated environment, model calls, and connections
• Open-source adapters he names: Postgres, OpenAI’s responses API, Docker, and other connectors
• On Vercel, as he maps them: Workflows for durability, Sandbox for secure execution, and Connect for short-lived ODC connection tokens

The Eve rewrite, and the Aura story without a score

They rewrote D0 in Eve while building Eve. The name stays D0. He says the earlier code, which the audience did not see, was convoluted. He has already said the live data agent carries about 100 distilled skills. The Eve file tree he shows for the rewrite is system instructions, a couple of skills, and a couple of tools, which he says are easy to compose and change. He does not explain how that couple of skills relates to the roughly 100 skills on the live agent.

A few beta customers had Eve before the public release he dates to about two weeks earlier in London. He gives no customer count. Partner Aura, which he says works closely with Vercel, rebuilt a small Claude-like agent that visits sites, installs services, and tries to use them. He says the Eve version needed fewer steps and produced better success and better insights than off-the-shelf Claude Code. There is no step count, no task definition, and no independent test. It is a partner anecdote, and he does not say what the agent installs.

Deploying Eve on Vercel, he says, shows agent runs, tool calls, steps, estimated cost, and possible optimizations. That list is the deploy view he describes. Qu names eve.dev and says people can clone a template, deploy, or self-host, and he does not describe a license or what self-hosting includes.

• eve.dev, the address Qu gives for a template, deploy, or self-host

What he says still has to be company-specific

Before relying on their own data agent, he says they tried well-funded startups’ vertical Snowflake agents, products meant to point an agent at a company’s Snowflake warehouse. He names none and reports no scores. His conclusion is that the useful part was Vercel-specific knowledge: what to query, and how a web company’s customers and properties link. An off-the-shelf agent, in that telling, is a starting point. The company knowledge is the part he says still has to be written in.

He claims roughly 20 Vercel agents with what he calls decent product-market fit, his label for agents that have found real use inside the company, not a defined metric. The examples he gives are marketing retros and outreach, a first-pass contract redline when legal sees a new negotiation, and the data agent.

The productivity claim stays qualitative. He says the agents save a lot of time, and the data team now spends time on Snowflake performance, missing sources, and gaps instead of writing queries all day. He gives no hours saved, no drop in query volume, and no warehouse performance numbers.

He closes on an opinion. Companies of any size, he says, can automate work people do not want to spend the day on. HR, finance, and sales can be somewhat automated, and Eve is the best way to build those agents today. That is a call to action from the stage. He does not show those functions already automated, or Eve measured against alternatives.