After
the demo.
What it takes to make agents useful once generating the code is the easy part.
Vercel Ship had plenty of launch announcements. Python. Persistent drives. Background workers. More ways to route models and connect agents to the things a business uses.
But the more interesting story was in the seams between the talks. Anthropic pulled the agent’s reasoning away from its execution environment. Notion described a memory handoff that failed even though the original agent gave the right answer. SAP showed how to generate an interface without throwing away twenty years of design knowledge. And Shopify’s Tobi Lütke described engineers spending their effort on systems that can verify what agents produce.
My read: the hard part is moving from an impressive individual run to a system that keeps doing useful work. That takes context, boundaries, feedback, and a clear definition of done.
The product is the feedback loop.
Guillermo Rauch opened with software factories: agents that can reproduce a bug, fix it, test it, and help get the change into production. The part worth paying attention to was the input. The agent needs production context: errors, traces, traffic, and evidence about whether a change made the experience better.
This changes what a deployment platform can become. It already sees the running application. If it also exposes those signals as tools an agent can use, it can connect what happened to what should be built next.
Agents make the request-response box feel small.
A web request comes in, a function does some work, a response goes out. Agents are less tidy. They may need to run code, wait for a person, retry a failed step, keep files, or continue tomorrow.
Vercel’s announcements filled in several of those shapes. Python was announced as generally available. Containers let teams bring their own runtime. Daemons were introduced for always-on background processes. Workflows handle recoverable execution. Drives, also announced as generally available, preserve a workspace independently of the sandbox running against it.
Separate the brain from the hands.
Katelyn Lesse’s Anthropic talk had the clearest architectural lesson of the day. Their initial approach was straightforward: boot a sandbox and run Claude Code inside it. But if the sandbox died, the agent died. Startup added latency. And credentials sat beside code the agent could write.
The revised architecture keeps the model, harness, and session state on a durable service. Sandboxes appear when execution is needed. They can fail without destroying the agent’s session. Credentials are injected at a controlled network boundary rather than handed to the untrusted code.
The detail I would carry into an implementation: the agent should not be able to edit its own monitoring or disable its own kill switch. Those belong outside the environment where it executes arbitrary code.
watch · 01:21:02 — the redesign · 01:34:18 — trusted controls and secretsMore tokens help when they have different jobs.
“Tokens should have jobs” was Lesse’s useful framing for multi-agent systems. An executor can do the work. An adviser can help with a difficult subproblem. A grader can compare the result to a rubric. A separate process can look across previous sessions and extract reusable lessons.
That is a more specific design than asking one agent to think longer. It also addresses a familiar failure: the agent that wrote the answer is not always a good judge of that answer.
Anthropic illustrated the difference with a seeded-bug experiment: dynamic workflows found 66 of 70 planted bugs in each of three runs; single-agent runs found between 14 and 27. That is an interesting result from a described internal experiment, not proof of the same gain on every codebase.
The next user may never see your UI.
Ora’s Asaf Elovic described agents trying to use websites: looking for documentation and prices, guessing familiar URLs, following links, and sometimes falling back to search. A polished page is not much help if the content is missing from the HTML a fetch tool receives.
The practical recommendations were refreshingly concrete: make important information readable, place it where fetch tools will retain it, link to machine-readable resources, and give agents tools for completing actions. An llms.txt file that nobody discovers does little on its own.
Notion’s Sarah Sachs added a sharper point: agent search and human search can need different interfaces over shared infrastructure. Her team had treated them as one problem, then split them. A human needs useful snippets and ranked results; an agent may need different recall, output structure, and progressive access to context. Removing unnecessary ranking work also removed latency in their system.
Shared storage is not shared understanding.
Sachs told a small story with a large implication. An external agent could answer questions about her credit-card benefits correctly, but left behind a pile of long documents. When she tried a different agent, it did not pick up what the first one had learned.
The work had been saved. The useful structure had not traveled. The first-party Notion agent knew conventions for databases, processes, and organizing information that the external interface did not fully convey.
This is also a product boundary. Vercel’s V team emphasized being able to change models while keeping conversation history, memory, and personalization. Notion described investing in tools and skills that convey the product’s own knowledge to agents it does not control.
Put the agent where work happens.
Then scope the room.
Vercel had already built an internal hub for its many agents. The problem: it was a separate web app with single-player conversations. So the team moved the shared entry point, V, into Slack, where questions, missing information, reviews, and decisions already happened.
The security detail was more interesting than the chat interface. V asks two questions: who is requesting the information, and who will see the answer? An employee asking in a company-wide channel does not automatically get to publish everything they personally can access.
Mercor made the same point at organizational scale. Its speakers described roughly 2,000 projects, many owned outside engineering, and an inherited identity layer rather than asking every builder to implement authentication. Their inference keys have owners, expiration dates, model restrictions, and spending caps.
Meta’s account of building with Vercel and AWS added a deployment boundary: fast previews and rollbacks had to coexist with code running in Meta’s own AWS account and access to private infrastructure. Bring Your Own Cloud was announced as generally available that morning.
“Connections are not context.”Matt Lewis · Vercel · 03:33:33
Connecting a database gives an agent the ability to query it. It does not explain your billing rules. And filtering the final answer does not make traces safe if sensitive information was logged along the way. Both business meaning and access boundaries have to be designed into the full journey.
watch · 03:17:28 — V in Slack · 03:34:13 — traces are a data surface · 05:04:30 — Mercor’s defaultsMove design knowledge into the generator.
SAP’s presentation was a useful antidote to the idea that generative UI means asking a model to improvise a screen. Their compositional design system starts with user intent and business context, plans what decisions the interface must support, selects suitable compositions from a catalog, and renders a specification.
The catalog carries more than component names. It includes when to use a composition, how to use it, and requirements such as accessibility and localization. That moves institutional design knowledge from a document someone might read into the process that produces the interface.
The demo showed a new people-profile composition being added to the catalog without changing the client. The agent could then choose it and request missing context, such as profile pictures. That is a compelling division of labor: constrain the rendering vocabulary, then improve the data and knowledge that guide composition.
Fast enough to change the interaction.
The fast-AI panel put two kinds of progress together. Cerebras works on inference hardware. TypeSafe AI’s Jev focuses on a different shape of model use: fast decisions and structured tasks inside software.
The interesting argument was that latency can change which products are possible. A classifier can sit in a request path, decide whether input is a command or dictation, or route work before the user feels a pause. That is different from a long conversation in which the user expects to wait.
Adapta’s Max Peters supplied the operational version. Their application-level router sits before the gateway. User feedback feeds a task-specific evaluation dataset, which helps decide which model handles each prompt. The gateway simplifies provider access; the router still needs knowledge of what works for that product’s users.
Jev also appeared in V’s request classification and SAP’s composition selection. The common pattern is useful: spend a small, fast decision on choosing the next action, then reserve more expensive reasoning for work that needs it.
The engineer’s leverage moves toward verification.
“We are now all verification engineers.”Tobi Lütke · Shopify · 06:22:39–06:22:52
Lütke described harnesses, acceptance tests, and verifiable systems as the new center of engineering effort. His example was a storefront-renderer migration from Ruby to Rust: a bounded domain where the team could compare the same input and output before changing which implementation served traffic.
That example matters because it names a tractable verification target. “Make this system better” is hard to score. “Produce the same output on this workload while meeting a performance target” gives the agent and the reviewer something concrete to test.
Several earlier talks converged here. The V team said to evaluate the whole journey, including interactions between specialists. Notion described using its evaluation environment to compare external agents as well as its own. Anthropic separated execution from grading. These are different ways of refusing to treat a plausible final answer as sufficient evidence.
ClickHouse added a data-infrastructure perspective: an agent run produces application data, traces, evaluations, and analytics. If those remain disconnected, diagnosing why a result happened becomes its own integration project.
watch · 06:22:39 — verification engineering · 06:25:25 — renderer migration · 05:29:54 — agent data and silosPeople ask for an outcome.
Agents assemble the basket.
Lütke’s most useful commerce example was not an agent clicking “buy” faster. It was a person who wants to decorate a house for Halloween, or do a 3D-printing project with their kids. The agent helps plan the project, identifies the missing pieces, and works backward from when they need to arrive.
He called this project-based commerce. The opportunity is to serve intent that was previously too much effort to turn into a shopping trip. His estimates about how much commerce agents might replace or add were speculation, not measured adoption or a forecast to build a financial model around.
He also left room for excellent human storefronts. The line he drew was between undifferentiated experiences and thoughtful, distinctive ones, rather than assuming agents eliminate websites. APIs and protocols can expose the transaction infrastructure while the customer-facing experience keeps evolving.
A useful agent is a system you can inspect.
The recurring pattern across Ship was not that every product needs more agents. It was that useful autonomy depends on the boring parts being unusually good.
| If you are building… | The question worth testing next |
|---|---|
| A coding agent | Can it reproduce the issue, pass acceptance criteria, and show evidence for its change? |
| A company assistant | Does domain knowledge travel with the tools, and are answers safe for the channel receiving them? |
| A long-running worker | Can it recover after execution fails without losing state or repeating side effects? |
| A generative UI | Are accessibility, consistency, and component usage encoded in the generation path? |
| A model router | Does it improve quality, cost, and latency on your real tasks, rather than a generic leaderboard? |
| An agent-facing product | Can a new agent discover, understand, act, and verify—without a human bridging the gaps? |
That is the thread I would take away from the conference: the model supplies more capability each year. The product work is turning that capability into something dependable enough to use again tomorrow.
Go back to the actual talks.
This article is based on the saved main-stage livestream from Vercel Ship SF on October 15, 2026. It covers the broadcast, including its long breaks, rather than every session on the conference schedule. The parallel breakout and Startup Studio programs are outside this article’s scope.
The saved broadcast is 6:51:35; the current YouTube replay is 6:31:22. Watch links and displayed timestamps were synchronized to the edited replay on October 22, 2026, using matching audio from both versions. Stills are reproduced as source evidence for the discussion and link to their moments in Vercel’s recording.