Vercel Ship 2026

Hello everyone, Kimi here from the Mercedes-AMG Petronas Formula 1 team. Welcome to Ship San Francisco. I hope you're ready to go.

Please welcome to the stage the founder and CEO of Vercel, Guillermo Rauch.

GM, GM everyone. Welcome to Ship SF. I love San Francisco, you know that, and it's my favorite city in the world. I love it because it's a place that people come to make impossible ideas real. That's why I came here, and it's why I started Vercel 11 years ago in this building. No joke. Right where you're sitting. Actually over there, but basically where you're sitting. So I wanted to start the day by telling you about something that would have seemed impossible to me back then. Right now on Vercel, you can deploy your own end-to-end software factory in less than three minutes.

This seemed impossible because four years ago, during the stone age, we were copying and pasting code from GPT into our editor. And then two years ago, we were coding with AI assistance. And then 11 months ago, Opus 4.5 came out and started to prove the AI deniers wrong. That was less than a year ago, and now we can actually do the impossible, like deploying fleets of agents to the cloud to run the software development life cycle. Headlines told us that those agents would replace developers, but that didn't happen. In the last 12 months, the number of developers building on Vercel has tripled. The number of new projects they launch has doubled. And the number of deployments they trigger with coding agents has grown 28 times. The haters said AI would take your job. But instead, you gave AI a bigger backlog, and you're shipping it really fast.

Look, it took us 10 years to get to 1 billion deployments, which is a lot. Now, you guys ship a billion deployments every four months. That's why I believe that in the next year, more software will be deployed than in the entire history of computing. And if that's true, it's time to update our system prompt for what's coming next. The things we ship in 2027 are going to look a lot different. Interfaces will be generated just for you, for the task you need to complete, and then disappear. When a bug is detected, it'll be reproduced, fixed, tested, and deployed automatically without a single prompt from you. Software will basically build itself, but it can't do that by itself. It needs production context.

Software will generate UI on the fly, but it actually needs to know whether it created a better user experience. That's production context. Software will repair itself, but that requires pulling errors right from the runtime. That's production context. Production context is what turns software into a loop. Because what happens in production drives what gets built next. And that loop runs on Vercel. And Vercel is agentic infrastructure. We built it for developers. Because the difference between a world full of slop and a world full of software worth using is you.

We give you everything you need to build any kind of software you want: agents, APIs, backends, MCP servers, Docker apps, full-stack apps, static artifacts that you deploy in milliseconds. But agentic infrastructure is also where your coding agents go to deploy that software. When you ask your harness, any harness, where to deploy, you get Vercel. That's because Vercel speaks the language of agents. We have over 200 CLI commands that your agent can use to orchestrate every aspect of the Vercel platform. You can tell your agent to create new routing and firewall rules, for example, in plain English or even Argentinian Spanish. That's what I do.

Your agent can provision a sandbox for your project or for itself in seconds. Your agent can even buy things on Vercel. It can buy a domain, so it has its own little house on the internet. No mortgage required. It can add services from the Vercel marketplace, like web search for your agents or payments for your storefront. And you can upgrade your plan with your permission, of course. So the third part of agentic infrastructure is that Vercel itself is automated by agents. They watch your apps in production across traffic signals, traces, anomalies, and then they don't just send you alerts. They autonomously investigate and optimize your projects, opening pull requests ready for you to review with your morning cappuccino. People call this the agentic development life cycle. We simply call it Vercel.

But I want to stop, take a step back, and think about this loop. A world where software can build itself. Because to developers like us, it can feel like we're living in the future. Of course. But I've seen this story before. Mercedes makes some of the fastest cars in the world. But they don't just win because of the car. They win because everything behind the car got faster, too. Their factory used to be humans building cars by hand. Today, it's humans working with robots, algorithms, building better cars in a fraction of the time. And the data from every lap is fed back into the system, finding optimizations in real time that the team can even ship before the car crosses the finish line. Every part of that system, the manufacturing team, the data, exists for one purpose: to bring out the best in the driver.

And that's exactly what we built Vercel to do. To put the full force of agentic infrastructure behind you guys. When you run your apps and agents on Vercel, your software becomes your optimization loop. While your competitors are stumbling trying to learn how to prompt, you're lapping them with factories of agents that build your ideas while you sleep. On Vercel, you and your agents deploy faster, your software runs faster, and you compete to win. This is agentic infrastructure, and I can't wait to see what you all build on it. Now, I want to invite up Malte, our dear CTO, to the stage to show you how it all works under the hood. Thank you.

Thanks, G. G told you about the Mercedes car, the factory, and the driver. I recently learned the Mercedes F1 has two factories: Brackley, where they build the car, and 30 miles away, there's Brixworth, where they build the power unit. And that's my focus, the engine underneath everything G just showed you. The first engine that we built was the front-end cloud. A request comes in, we run your JavaScript, and we return a response faster than anyone in the world. And we got pretty good at that. Now, we process two trillion requests a month. But software does not stop at the front end. It's APIs and services, workers and jobs, workflows, and data. So we had to build a new engine, one that could power any full-stack app or agent.

And fortunately, there was a German nearby. The first requirement of this new engine was simple: you should not have to rewrite your backend to run it on Vercel. And for many of our customers, that means Python. So today, Python is generally available on Vercel, and notably, it's standard CPython. Dependencies from PyPI, with uv and pyproject, bring Django, FastAPI, or Flask and run them as they are. Functions can run for hours or even days, with individual requests taking up to 30 minutes. And with Vercel services, your front end and Python backend ship in one commit, and you get a unified preview for the entire app.

150,000 teams already run Python backends on Vercel, including companies like OpenAI, Hugging Face, and Cognition. Delphi is one of them. They run agents that turn books, speeches, and podcasts into a digital brain you can talk to. For instance, you could feed it every talk I've ever given and carry me around in your pocket, though I hear my wife would not recommend that. Delphi has 10 engineers who ship to production more than 100 times a day, and their backend is written in Python and TypeScript both.

When someone uploads a book to create a digital brain, Delphi's agents process it into a knowledge graph and then generate content from it. Vercel workflows makes those long-running agents doable. If a process crashes when someone uploads a book, the workflow resumes from the step that failed. And then Vercel queues handles the background jobs with both runtimes, Python and TypeScript, publishing and consuming from the same queues. So Delphi runs a durable Python backend all on Vercel. But our customers have services that require a lot of other runtimes too. Maybe it's written in Go or Rust. Maybe it depends on a system library. Maybe it was written in 2011 and you really don't want to touch it anymore.

When you need your own runtime or dependencies, you can now ship them as containers on Vercel. Give us your Dockerfile, and we'll build the image, run it on Fluid Compute, and treat it like any other Vercel deployment with previews, rollbacks, logs, and automatic scaling. Since June, 5,000 teams have shipped 150,000 container deployments on Vercel: Go, Rust, Ruby, Zig, and Java, which I did not expect to say on our Vercel stage.

Now, I want to tell you about one of Vercel's biggest backend customers. It's Vercel. For most of our history, if you asked whether Vercel runs on Vercel, the honest answer was the front end does. But we manage the backend APIs, services, and workers ourselves in Kubernetes. This is what the backend of our control plane looks like. There are a bunch of API services running on Kubernetes for things like the dashboard, the CLI, the integrations. And then there are a bunch of asynchronous subscribers handling things like git-triggered deployments, data retention, cleanup, and usage data, that type of stuff.

After we built a new backend engine, we started to migrate APIs from Kubernetes to Fluid Compute. And now we run over 25 microservices on Fluid. And importantly, the developer experience for my team is, well, the Vercel developer experience. And that means we barely spend any time operating these backend APIs. And they already run at massive scale. We process over one billion API requests every month on Fluid Compute for ourselves, and that number is growing fast. So bring us your APIs, and we'll run them on Fluid just like our own.

All right, now I know what all of you are thinking: but the async subscribers, they're still on Kubernetes. And you're right to be honest, they're just not a good fit for serverless because they're always on. We tune in to make sure our platform has healthy throughput, but that is about to change. Today, we're announcing Vercel Daemons. Daemons, they're now in public beta. They're our new compute primitive, tailor-made to give you the awesome zero-ops experience of Fluid Compute, but optimized for the most demanding background processing.

Give us your code container, the number of instances you want, and we'll keep them running and replace them if they fail. You can run Celery, Dramatiq, Temporal, or your existing worker processes. And I can finally say, remember when we used to manage Kubernetes clusters by hand? So that's the front end, the API, the workers, they all run here. Vercel now runs on Vercel, and you can too. Your full-stack app, your API, your Python backend, your containers with any runtime, your workers and subscribers, your agents and durable workflows. You can build almost anything on top of Fluid Compute. And now I want to invite Tom Occhipinti up on stage to show you how.

Thank you, Malte. Hello, everybody. It is so great to be here with you today. So earlier G said that we give you everything you need to build agents. We've collected all of these building blocks into what we call the agent stack. It all started with the AI SDK. AI SDK is our TypeScript library for calling models, defining tools, and streaming responses from any provider. It's one of the most popular open-source AI projects in the world, with over 30 million downloads a week. But model calls are now just one part of long-running agent jobs. That's where the Workflow SDK comes in. Workflow SDK makes your agents durable. You define steps right in your agent code instead of wiring up a separate orchestration layer. It saves their results, retries failed steps, and even waits for a webhook or human approval. Most of our customers leverage these building blocks through AI SDK. AI SDK is our open-source framework for production agents, and developers are building some really cool stuff with it.

For example, Sora's AI SDK agents perform healthcare research for banks and hedge funds. Aura's AI SDK agents test whether your website and product are agent-friendly. Dana is a personal assistant built on AI SDK that can clear your inbox, book your meetings, and even shop for you on the web. And Vercel built an entire software factory on AI SDK. Now their engineers ship three times faster. And since we launched AI SDK in June, my team has been very busy shipping many of the features you've all been asking for. AI SDK agents now have persistent memory, so they can remember useful context across sessions and carry it into the next conversation. With AI SDK extensions, you can install tools and skills instead of writing every integration yourself. One command, and your agent can browse the web, click buttons, fill out forms, and take screenshots. And you can now build and deploy an AI SDK agent straight from the Vercel dashboard in less than a minute. This includes a system prompt, integrations, a web interface, and MCP connections. It's the fastest way to get an agent into production today.

So, that's what's new with AI SDK, but we've made some great updates to the rest of the agent stack as well. Vercel Connect is now generally available, and our integration catalog has grown to over 1,000 connectors. But what I'm most excited about is that Connect can now subscribe to events from MCP servers. Normally, when you want an event to trigger an agent task, you have to authenticate with each server, create the subscriptions, and receive and verify the incoming events. Now, you just choose the MCP server and the events your agent should listen for, and Connect handles the subscriptions, renewals, and secure delivery from there.

Moonpig built an agent called Clause. Employees ask it about company policy in Slack, and it answers using documents the legal team keeps in Google Drive. They use Connect for authentication and the events that trigger Clause, which means their engineers aren't maintaining token refresh code, signing secrets, or event subscriptions. The Kernel team built a voice-controlled browser agent. You give it spoken instructions, and it writes and runs Playwright code to control the browser. With Connect, people sign in and use their Kernel and AI Gateway access, and there's no API keys to hunt down or store in the app.

Connect gives your agents access to other systems, but they also need access to models. And that's where the AI Gateway comes in. AI Gateway gives you hundreds of models from dozens of the best providers through a single API with no markup. The average enterprise on Vercel routes across 17 different models. So routing isn't really optional for production agents. You can test a new model by changing a single string. And if a provider goes down, Gateway seamlessly falls back to another one. For every request, you can see which provider served it, how long it took, and what it cost. And cost is a big deal because some folks on our team haven't quite moved past token maxing. You know who you are.

But for real, if an agent gets stuck in a loop, it can get really expensive. So, we built spend control directly into AI Gateway. You can now set budgets for individual keys, projects, and even your entire team. But tokens aren't just about money. You send your data to models, and you should have control over how they use it. That's why AI Gateway doesn't retain any data. And we carefully consider every one of the providers we work with so we can offer you features like zero data retention. Every single week, we turn down free token promos from providers that don't meet our standards. And critically, you can also route through providers who process your data exclusively in the United States.

Over 400,000 customers run their production workloads on AI Gateway. And we serve over 4 trillion tokens a day. And today, we're launching Token Pass in early access to give you even more of those tokens for every dollar you spend on Gateway. For $30 a month, you get $80 to spend on GLM 5.3, Kimi K3, on AI Gateway, with more models on the way. You can use Token Pass with any coding agent, and it's designed with privacy in mind. Zero data retention is on by default.

I love what Tailscale has built on AI Gateway. They shipped a model router inside their own product. Tailscale connects your company's computers on a private network, and then their router gives employees and agents on that network access to approved models through AI Gateway. No provider API keys to manage, and they still pay the same token price they would if they had gone direct. Okara is another Gateway customer. Their marketing agents can find an SEO problem on your website, investigate it, and open a PR to fix it. To power those agents, they used to maintain eight separate model provider integrations. AI Gateway replaced them all with a single API. Now, their agents can use new models the day that they're released. But the most impressive part is this: their entire team is just four people, and they serve over 4 billion tokens a day.

But Okara's agents need more than tokens. They also need a place to run code, and that code has to be run safely, which is why they use Vercel Sandbox. Vercel Sandbox exists because every agent needs a computer. Each sandbox is an isolated Firecracker microVM with its own kernel and file system. It gives your agent secure general-purpose compute. Your agents can install dependencies, start services, and run tests against your application. Our customers start over six million sandboxes a day, and they're doing some amazing things with all that compute. For example, Notion built part of their developer platform on Vercel Sandbox. To create custom agents, developers write functions and run them in Notion Workers. Each custom agent runs in its own Vercel sandbox, so data and agent code stay completely isolated.

Conductor brings that same isolation to coding agents. They started by running an agent fleet for you on your local machine, and when their users asked for a cloud version, they built it on Vercel Sandbox. They told us sandboxes spin up so fast their customers couldn't tell the difference from when they were running locally. But even though our sandboxes are fast, maintaining your agent's workspace meant snapshotting the file system. You had to restore data and results from the last run before your agent could move on to the next task. What our customers have been asking for since the beginning of Vercel Sandbox is a persistent workspace they could manage independently from the sandboxes. So today, very excited to announce the general availability of Vercel Drives.

Mount a drive, and your agent keeps its code, data, and saved memory across runs. The drive persists your workspace, so the next sandbox can mount it, and your agent can pick up where it left off. You can update the runtime, give your agent more compute for a complex task, or hand the workspace to another agent. And several agents can use the same installed dependencies through read-only snapshots. With Sandbox and Drives, you can run stateful agents on Vercel.

And that's the agent stack. Millions of developers are using it every day, but they're actually not the only ones building with the agent stack. I'm excited to invite up our COO, Gan, to talk through how anyone at Vercel can ship their own apps and agents with the agent stack, and how we keep it all secure. Thank you.

Thanks, Tommo. G told you earlier that AI isn't just changing the software we build or how we build it. It's changing the way entire companies operate. Company building has become agent building. And my job is to make that happen for Vercel and our customers. That puts me in the room with a lot of executive teams, and everyone tells them the same thing: building is getting easier, but control is getting harder. At Vercel, our marketers, analysts, and sellers are building and deploying their own apps and agents. They aren't engineers, they're citizen developers. They know more about their part of the business than anyone else. And now they can build the software they need to make it better.

They create dashboards, research agents, campaign plans, and all the kinds of tools that make them faster and better at their jobs. And citizen developers are building at your company, too, whether you know it or not. If you don't know it, that's called shadow IT. And it can create some serious problems. When a well-meaning citizen developer vibe-codes a login page incorrectly, your private data is suddenly on the public internet. That is not going to be a fun call with your CISO.

Every leader has to figure out how to let everyone build without giving up security or control. But control isn't the end goal. Like G said, you want to compete to win. That means shipping the best ideas in your company, no matter where they come from. And that's exactly why we built Enterprise Apps and Agents. It's a central control plane for governing every app, agent, user, dollar, and token. And it starts with controlling who can actually ship. Vercel works the way any enterprise platform should. It connects to your existing IDP, so you can control who creates deployments. That includes citizen developers and engineers. When you remove someone from Okta or Entra, they lose access to deploy on Vercel.

Next, you have to limit who can use the apps and agents that get deployed. On Vercel, every deployment is private by default, so you can even restrict access to a single team or group down to the data. At Vercel, our sales leaders can see the full forecast in our revenue dashboard, but when reps log in, they can only see data from their accounts. But human access isn't the only type of control you need. Agents are only useful when they connect to your systems themselves. That means your CRM, your database, your Slack account, which all contain sensitive data. Normally, that means storing an environment variable tied to a user account with never-ending god-mode access. On Vercel, you control the exact scope of every integration. Agents connect with their own identity, and credentials are only minted for the task at hand. And now with Enterprise Managed Authorization, you can give agents across entire teams access to services like Slack right from their identity provider. Employees sign in once, and their agents can use those services on their behalf with no extra sign-ins.

And of course, behind all these apps and agents are the models themselves. Every model call sends data and consumes tokens. So you have to control which models people can use, how providers handle your data, and how much your builders and agents can spend. Vercel's AI Gateway gives you a central place to manage access to hundreds of models. You can also set global data retention policies and track every dollar against a set budget. All of this comes together in a single control plane behind the identity and security systems you already use. All of your apps get enterprise observability, whether it's an internal product or a product you deliver to customers, and they run on the same secure infrastructure that powers billions of deployments at scale.

CTOs tell me one of the biggest reasons they choose Vercel is that the platform is open. Citizen developers use different tools, and so do engineers, even at the same company. A marketer might build a landing page with ChatGPT. A data analyst might use Claude Code to query Snowflake and create a report. Engineers might use OpenCode, Bolt, or FX. And tools like Dots and Muse are making it possible to build something with a single message from your phone. Without a central control plane and deployment target, you can't govern where apps are published and who can access them. Vercel gives you a single secure place to deploy and manage every app and agent, no matter what your builders are using to generate the code. But deployment is only the first step. Everything that ships will run in production. And security is even more important and more complex.

Even if an app is private, it can still expose credentials or use a vulnerable dependency. Multiply that by hundreds of apps, and a security incident is inevitable. Vercel gives you a single place to see your security posture across every deployment. The security dashboard is a global view of vulnerabilities, misconfigurations, and risks that need investigating. And it even shows you where to fix them, so you can take action before a stale dependency becomes a data breach. But control doesn't stop at security. Like Tommo said, those hundreds of apps are all burning tokens, too. And that can get expensive. That app your marketing manager built probably doesn't need to run Fable to summarize call transcripts all day long. And they probably didn't need to use Astra on extra high to make all those little tweaks to the UI. On Vercel, you can set budgets for every user and project. When they hit a limit, we stop serving tokens. So, when you run on Vercel, everyone can build, but no one gets a blank check.

There's one more question I want to tackle. It's a question that Meta Superintelligence Labs asked us at the beginning of the year: where do all these apps run? For Meta's AI team, the answer is they run in their own AWS account. They get the full Vercel developer experience in an environment they control, and it completely changed how fast they can test new ideas. They told us that in their first week on Vercel, they shipped an entire month of work. This year, the team launched products like Muse Code and Muse Wonder, and now you can give your teams the same experience as Meta. Bring Your Own Cloud on AWS is generally available today.

We launched Enterprise Apps and Agents in June. Now thousands of engineers and citizen developers across hundreds of enterprise companies are building on it, and you're shipping some amazing things. Klaviyo uses Vercel to let anyone in their company build internal apps and agents. Before, shipping a simple tool took two weeks of chasing it, following up with engineering, and asking for favors from the platform team. Their process filtered for people willing to wait, not the best ideas. Today, anyone at Klaviyo can go from idea to working app in three minutes. Everything they ship is protected by SSO, and builders can even connect their apps to internal databases securely. In the first two weeks after moving to Vercel, 512 people deployed 356 apps. That's one in every five Klaviyo employees shipping.

But Enterprise Apps and Agents isn't just about internal apps. Mercor connects leading AI labs with subject matter experts who help train models. Hundreds of engineers needed access to models to do that work. But access was spread across direct integrations and third-party routers. That made stolen credentials a huge risk and budgets impossible to manage. They moved all their routing to Vercel's AI Gateway. Now they can give each engineer access to hundreds of models with a single expiring gateway key. They can set budgets for people and projects. They can see where every token goes in a single dashboard. And Mercor tracks a lot of tokens. In their first 10 days on the AI Gateway, they served 63 billion tokens without hitting any rate limits. You'll hear more about that from Mercor on stage later today.

On Enterprise Apps and Agents, you can ship everything from internal tools to customer-facing software at massive scale. And that's exactly the path we followed to build Vertex, our customer support agent. Last year, we were using a vendor to process support tickets, but it couldn't answer some of our customers' most important questions. So, our support team started filling in the gaps themselves to improve our response times. They built agents that could investigate different types of customer problems, then determine how to fix them with knowledge and skills.

We realized that what they built was actually the foundation of the support experience we wanted to deliver directly to our Vercel customers. So they handed their work off to our engineering team, who built a full customer support agent. The support team knew how it needed to work, but the engineering team made it production-ready. They built evals from real support questions and gave agents access to more data. They also added model failover so it could still give answers when a provider went down. Today, Vertex handles 91% of all Vercel's support cases by itself. What started as a few agents built by our support team now handles thousands of cases every week. And it all happened from the same platform. That's agentic infrastructure.

Engineers can ship the best ideas at global scale, and everyone can build. And the platform gives you control over every user, every deployment, every dollar, and every token. Company building is agent building, and we can't wait to see what you'll build on Vercel. G, back to you.

Thanks, Gan. Vercel started as the fastest way to deploy your front end. Today, you saw that we're building the fastest way to deploy anything, like your backends. Vercel officially is Python-native. Our containers can ship any runtime you bring us. And now with Vercel Daemons, you can deploy always-on workers without managing the machines underneath.

If you want to see your backend running on Vercel, it's simple. You know it. Import a repo, click deploy, and we'll give you a live preview of production. Vercel is also the best place to deploy agents. AI Gateway gives them instant access to hundreds of models. Connect gives them thousands of secure integrations. Sandboxes give them their own personal computer. And now with Vercel Drives, you can ship stateful agents that have a persistent workspace.

If you haven't deployed an agent on Vercel, do it today. It only takes one minute. Now imagine everyone in your company shipping their ideas that fast. That's Vercel for Enterprise. Anyone can create agents with the tools and models they want, and every deployment is private by default. Every API key and every project has its own token budget, and you can even bring the Vercel developer experience to your own AWS account.

If you want to ship fast with AI or ship safely, I'd love to talk with you. My DMs on LinkedIn are open. Look, when I started Vercel, Next.js was just an idea in a folder on my laptop in my backpack. And I'm amazed at how far we've come. Four trillion tokens a day, a billion deployments every four months, 60 million Next.js downloads a week, 150,000 teams running Python on Vercel, over 100 new sandboxes every second.

And for 10 years, we've been obsessed with building the fastest, most powerful infrastructure in the world. All for one reason: to put that power in the hands of developers like you. So you can build a future on your own terms, with your agents and your data and the models you choose, to make your impossible ideas real. We can't wait to see what you ship next. Thank you.

Let's go San Francisco. Welcome to Vercel Ship, everyone. I'm Madison, head of startups at Vercel.

And I'm Melky. I'm one of the staff engineers here at Vercel. We've got an insane lineup. We got 12 sessions to get through today with the founders from your favorite consumer, infrastructure, and frontier companies.

Our goal today is simple. We're bringing you into the future of how agents are shaping and shipping our everyday lives.

So, you don't want to miss it. But first, go stretch your legs, grab some coffee, take five minutes. We're going to be back at 11:15, and we're going to kick things off with Aura and Anthropic. So, I'll see you guys there. Thank you.

See you soon.

All right. All right. Welcome back, everyone. Aura's whole product is testing whether a website actually works for AI agents. They send real agents at a site to sign up, integrate, and pay, then trace every single step. Assaf Elc, co-founder and CEO, built that on AI SDK, Vercel's open-source framework for durable agents. Aura benchmarked AI SDK against every major agent harness on the same model and task, and it finished more jobs in fewer steps. He'll walk through what hundreds of those agent runs reveal where sites break, and score a live site on the spot. Please welcome to the stage Assaf.

Hey everyone, my name is Assaf Elboher, and I'm the co-founder at Aura. It's so great to be here today. Today I'm going to talk about one of the fastest-growing topics in the agentic web, and I think many of you have already seen this across many Twitter threads and sites and everything you're seeing. I just want to give you one number, and that's that agents have grown in the last year by over almost 8,000%. And they're expected to grow by a thousand X over the next five years.

And to signal even more how much this is important and happening now, for the first time in web history, agents have just crossed human traffic on the web. And some estimate that they're supposed to grow to be around 99% of that of the web by 2030.

So there's a nice quote I like saying, which is, we spent 20 years keeping bots out, and now we have to let them in. And some of the largest companies in the world are already doing so. Salesforce, if you've seen this a few months ago, have just launched the headless 360. And this is, yeah, I want you to think about this for a second, because this means that a company that was focused on building the best CRM in the world is now exposing all of that infrastructure for agents. And even more, I'm sure many of us know Sentry, who has been very well known for such great human experience and observability, have now done the same.

We at Aura believe that agents act, see, and think very, very differently from humans. Which is why we like to term something new, which we call the agent front, which is basically a front end for how agents interact and use your website and your products. An agent front is a whole big new category, a whole new stack of protocols and ways to optimize for agent experience. And today we're going to focus on that. What is the agent front, and how you can start building it today.

So, at Aura, we study how agents make decisions on the web and what makes them use your site. And we conducted one of the largest-ever research efforts and spent a lot in order to understand how they act on the web. We defined thousands of intents across over 10 to 15 top agents we all know on over 120,000 sites. And as you can see, we've learned that only 4% of the web is barely usable by agents.

So let's take an example of how we did this. As you can see, this is something we call Journey. And you can check this out on journey.aura.ai. Basically, we define an intent, a model, and a site. And then we run an agent on that intent and start to trace what it actually does. And as you can see here, this is an actual example of what happens when an agent, for example, looks for pricing on an average site. The first thing they usually do is they go to your homepage, and right after that, they try and look for your docs page. And if you don't have a docs page, they're going to start making all kinds of URLs up, and they're going to fail, and then they're going to do web search. And ironically, we've actually seen real cases where they end up in your competitor's website.

And what we do at Aura is we try to find the best way to make the path look like this. So, the web isn't ready for agents. Let's see if you are. I want everyone to take out your phones and scan the following QR code. And this QR code is going to lead you to a site that we built together with Vercel, isagentic.com, that helps any one of you just enter a URL, and we're going to try and find out how much your site is usable by agents. So, let's give you 30 seconds to go into the QR code, put in your URL, any URL. It could be your personal website, it could be your business, it could be anything, and run that scan right now.

And what we do when we check, we actually check basic stuff such as: can an agent actually access your website? Can an agent read your content? Can an agent use you? We check for the most top trending and usable protocols such as MCP and so on.

And for some reason, and I'm just guessing, okay? And please prove me wrong if I am, but I'm guessing that your score was not very high. But I want to assure you that you're in very good company because some of the top, most biggest companies we know score on average 41.

So today I want to share with you some of the learnings that we did and we learned, so you could now try to improve the score as we speak. So let's play a game of true or false. Let's start with an easy one because I have a feeling that this one is a bit known by now, but agents read your LLM.txt. Raise your hand if you think this is true.

Surprisingly, it's a good one. False. We did a very deep research about in what cases do agents actually access an LLM.txt file and found that only 32% of the cases they actually reach it. But that actually sounds pretty high. So just to be clear, out of the 32% of the times they access an LLM.txt, in 86% of cases it's because the site somewhere pointed to it. Meaning that if you didn't point to LLM.txt in your site, there's almost zero chance that an agent actually accessed it.

Let's do another one. I feel like this is also a bit easy, but, you know, we're warming up. Agents see the same page you do. This time I'll skip the hands because we want to move faster here. False. Now for engineering it's pretty obvious, and even for engineering and developers, we found that it's not very obvious because actually, as you can see on the left, humans see the page with components and UI, but agents see HTML. And more surprisingly, we've seen that most of the harnesses, and specifically Claude Code and other kinds of agents, they actually use third-party tools to do web fetch, and those third-party tools actually trim only a subset of the page.

So, it's not just that the HTML pages contain almost zero text or content that agents can use, but even if you did think, let's put the answers in, the agents might have trimmed out most of the content. Now, those of you who are like, well, yeah, they can just spin up a browser, right? So, yes, they can spin up a browser. They could take screenshots of the pages, but we found that when they do that, they spend 45 times more tokens and over 23 times more time to complete a task.

Let's do another one. And this is a test if you were listening early on, because I actually said the answer to this, but agents guess your URLs. True or false? Let's see. True. In 35% of the cases, an agent starts to make up URLs before it even does web search.

And this is why one thing that we like to recommend a lot, because we've seen that the top pages it makes up are /pricing, /docs, and /api. And there's really good intuition to this, right? Because when you think about what I said earlier about agents acting very differently than people, the way for an agent to understand how to interact with your site is through integration, is through API. And this is why we've seen that in most cases, these are the top pages they look for. So it's not just enough to make sure that you have those pages. Even if you don't have APIs, create that page and route agents back to where you want them, because they're going to try and access those pages whether you want it or not.

Well, this is a bit more surprising. So, let's see how many get this right. If an agent can't read your site, it answers from memory. And just to specify what this means, it means that if they can't get the information, they will use their training data to answer the question. True or false? This time I do want hands because... True. How many? Oh, wow. Okay. False.

This is really interesting, and this has a lot of impact on entire categories such as AEO that have been around since 2023. And I want to give you a bit of intuition to why we've actually seen a decrease all the way down to 7% from our research that we just conducted. The intuition is pretty simple. Back in '23, models were just models. No tools, no multi-step reasoning. We heard the word hallucination in almost every conversation, right? So models did a lot of work to fix that. And if we speed up to 2026, models are trained on using tools, grounding their answers, doing multi-step reasoning, and all that compounded into much more web search and much more access to websites. So again, even if all you care about is optimizing for discoverability and being recommended by agents, we highly recommend making sure your site is readable and accessible.

And let's just take another example just to build your intuition. You probably imagine that when an agent accesses your site, it looks something like this, right? Goes to your site and navigates the pages and finds the answer. And back to what I was saying earlier, this is actually how it looks like in most cases. An agent tries to reach your site, it's blocked, it does the web search, and then it starts to find the answer. And if your competitor did a good job being readable and accessible by agents, they end up winning.

One last one. Closed models are better at web tasks than open-source models. False. And this is also very surprising. We've seen that open-source models actually win by just 2% over closed-source models in web tests that we've done. But that's not the interesting part. The interesting part is actually hidden very small in this slide, if you can see it, which is what is the cost of running an open-source model versus closed-source on the same tasks. And basically the takeaway from this is that if you're a harness builder, if you're building agents that have to do...

Web tasks, you're actually based on this research more likely to succeed with much as much significant less cost by using open source models such as DeepS.

So let's talk quickly about how we built this. And we're really proud to be partners of Versel. And it's almost crazy that our entire stack of running this very, very heavy compute-heavy research is all done on Versel infrastructure and specifically Eve.

And we actually tested Eve. We wanted to see if Eve is really the right fit for us. And when we actually found that in comparing Eve to other harnesses such as Cloud Code, Eve won in most of the most important KPIs that matter to us: 7% less steps, almost two times more success navigating on a site versus trying to find information through web search, and even 9% better at guessing the paths versus other harnesses such as Cloud Code.

And building with Eve is actually super easy. You have one directory, and the way we did it is we just defined we have an agent file where you define the model, and you can also use either the Versel AI gateway or an external one. You have a file for the instructions. You have a file for tools, in our case, browse, fetch, and finish. And finally, the sandbox environment in which you want to run the harness and evaluations.

And if there's even custom things that you need, like we did in some cases, you can add custom sandboxes in a matter of seconds and a few lines of code. And Eve is so powerful that we actually use it twice. We use it once as an orchestrator for every incoming request, as we've seen earlier in Journey Ora AI. But we also use it as a harness that you can now go to Journey or AI and actually select Eve as a harness and test it for yourself and see how well it runs versus others.

We also have an answer engine that we've built aside of our cell for the more other types of harnesses and agents such as ChatGPT and Claude through a browser. And eventually we were able to run this every single week for hundreds of thousands of sites all on Versel infrastructure.

So let's summarize with what you can do now to fix your score today. One, be readable by agents. We can't stress this enough. And I want to stress this even more by saying that you're losing agents today. Do this today. Link LMCX from home and docs. Those are the top two pages that agents reach. Put the content in the HTML. And as I said earlier, it's not enough to put it in HTML. Put it at the top of the HTML because that is what is trimmed when agents fetch website URLs. And lastly, create markdown twins for every page that you think is important for agents. Make it easy for the agents to read and understand you.

And secondly, let agents in. It sounds so obvious, but we've actually seeing more and more failures coming from sites. They're just blocking agents altogether. And we believe that this problem is going to be one of the biggest problems of the agentic web because it's not that easy to let them in. Bad bots still exist, and many site owners and many businesses still need to make sure that sites, bad crawlers, fraud bots, and so on, still exist, and they're actually becoming much, much smarter. So we know that letting them in is a complex task, and it's a task that we're obsessed about at Aura that we're trying to solve with our partners.

And lastly, give them tools. There are such incredible protocols out there. Even the latest WebMCP, which has been got incredible adoption, help them use your site, not just read it. And after you do all those six, go back to either isogentic.com or aura.ai, run your site again, and you'll see how fast and how much impact you can create today and even more. So, thank you very much, everyone, and feel free to reach out. Thank you.

All right. Kayn Les runs platform engineering at Anthropic. Getting an agent running is the easy part. She's covering the harder half: keeping it fast and actually improving across thousands of live sessions with the specific practices Anthropic uses to tune performance once Claude managed agents are in production on Versel. Please welcome to the stage Kayn, head of platform engineering from Anthropic.

Uh, oh yeah. >> Thank you.

Good morning. Excited to be here at SHIP with all of you guys. Thanks to Versel for having me. I'm Caitlyn. I lead platform engineering at Anthropic. Um, platform at Anthropic is the cloud platform, our API suite as well as our product infrastructure and our foundational services. Um, and so today I want to talk about how you can build, not just build agents. Everyone's talking about how you can build agents, but how you can build agents that can tackle your most ambitious workloads, your highest performance agents, um, and to do so securely. Um, and the nice part is that our friends at Versel have partnered a bunch with us on how you can plug in Versel solutions and infrastructure directly with our, uh, agentic solutions. And so, let's get into it.

So, let's pretend it is early November and you see a Slack fly by from your COO asking an agent, 'Uh, today at our e-commerce company, we only sell in the US. Black Friday is in three weeks and I want to sell in 24 new countries by then.' Um, which is crazy, completely crazy. Um, but maybe with today's, uh, the power of agents, we can get this done. Um, and so if you think about all the work that would have to happen in order to sell in 24 new countries, um, in three weeks, you might think about stuff like engineering obviously, right? Like you've got to build your new checkout flows and make things work. Um, but think about everything else around the edges of just engineering. You need to think about legal stuff, right? Like terms and conditions in all these new countries. You've got to think about finance and pricing, taxes, foreign exchange, all these sorts of things. Marketing, a brand campaign that works well in each country. Support, um, logistics, right? How do you actually ship, um, into those countries? And then of course you get to engineering. So this is a highly ambitious task that we're going to tackle.

So let's talk about how you could use cloud managed agents, um, with Versel in order to get this task done. Um, and so cloud managed agents is Anthropic's suite of APIs for building agents. Um, if you've built agents on top of the cloud API, you may have, uh, worked with the messages API. The messages API is our stateless API that basically gets you tokens. Um, but of course, as models have gotten better at running for longer and tackling more ambitious tasks, more people were building agents that would run, uh, in the cloud. And so we built, uh, a suite of APIs that helps people run their agents in the cloud. We call this cloud managed agents.

Um, and so starting with just the architecture of how we think about this, when we first set out to build an agentic API, the first thing that we did was we actually just took, um, a sandbox. Whenever an API request would come in, we'd boot a sandbox and we would just boot up cloud code inside that sandbox, which seemed like a perfectly reasonable thing to do to build an agentic API. We had three problems with that though. Um, so the first was reliability. Uh, if your sandbox dies, your agent dies, which wasn't great. Uh, then you've got latency. In order to actually even just get a token back out of that API, we would have to boot a sandbox each time and boot cloud code within that sandbox. And so you're kind of waiting a lot of time before you can start to get tokens streamed back. Um, but third and most importantly was security. Um, everyone's thinking a lot about security. So I'm going to spend a lot of time on security actually in this talk. Um, if you have an agent running within a sandbox, that means that you have credentials inside the sandbox with untrusted code that the agent is choosing to write, which means that, uh, you know, the agent could choose to use those credentials and go out over the internet and take actions that you may not want. Um, so we don't want credentials in the sandbox either.

Um, and so we redesigned this before we shipped publicly and we did what we called pulling apart the brain from the hands of the agent. Um, and so what that means is we've got a harness running just on a durable server and we're spawning sandboxes just when we need to execute work. Um, and this solved all three of our problems. If the sandbox dies, we kind of talk about this like treating them as cattle and not pets. So your sandbox can die, it's fine. Your agent is over here on a durable server with its storage and everything keeps going. Latency was much better because now we're just looking at like literally milliseconds on top of the messages API to run that harness on a durable server and get tokens back. Um, no more booting the sandbox and booting Claude Code in band of the original request. Um, and then security. We now have Claude's untrusted code running in a sandbox separate from credentials, separate from access to the model. Um, which is great.

And so what's great about this is we were able to work with Versel to plug in Versel's solutions to multiple parts of this. And so with this kind of brain-hand separation, um, your hands at the bottom can run on Versel. So you can run a Versel sandbox and plug Versel sandboxes right in, um, to cloud managed agents. And I'll talk a little bit more about this in a bit, but you can use the firewall that comes with Versel sandboxes as a proxy to inject credentials at the right time so that you don't have credentials inside of the sandbox. And then of course in the middle layer, you've got, um, your brain, that's cloud managed agents, that's the model, the harness, um, the session store, things like this. Um, and then you've got the front door. Um, my team sometimes likes to call this the eyes and the mouth, and I think that's a little too creepy, so I'm going with front door. Um, where you can use Versel's chat SDK to create, um, an interface to interact with agents and then of course you can build and host, um, a Next.js app in order to embed your agent and have kind of your full agentic system that you can work with.

And so starting with the chat SDK, this is actually really simple. Um, we've published guides for this. It plugs in really, really nicely to use the chat SDK with managed agents. And so that interaction that I showed earlier where the COO is asking the agent to do a bunch of work, um, that integration, uh, can run just straight through the chat SDK with managed agents. And then there's a sandbox. Um, and I think this is pretty interesting. So spending a second here. The way that we've designed this is when managed agents wants to do work, what it will do is put a job kind of on a queue and then we'll send a webhook to a Versel function. That Versel function will say, 'Okay, great. I need to boot a sandbox now.' And then we'll kind of pipe back in and grab work off the queue from managed agents. Um, which is great because from a security perspective, it's nice that you've only got outbound HTTPS going back into managed agents.

So that's kind of high-level architecture how you would build agents with cloud managed agents in Versel. Um, but that's maybe not quite as interesting as actually making those agents really powerful. Um, and at Anthropic we're spending a lot of time on this. How can we harness the intelligence of these models that are kind of getting exponentially better to create really powerful systems? And the thing that's most top of mind for us right now is multi-agent strategies. That's the best way to kind of get the best intelligence out of models.

And so a concept that we've spent a lot of time on is this idea that tokens should have jobs. And really what this means is if you want to get really hard work done, you could throw a lot of test time compute at the problem. You could just execute, execute, execute, but you're probably not going to get quite as good of an outcome as you would if you spent some of your tokens on some other jobs around the edges of executing. And so what does this, what does this actually look like in practice? Um, one example of this is advising. You could have a smaller model that's executing and a larger model that the smaller model reaches out to for help and you'll overall probably get, um, a higher quality outcome. And so going back to our let's launch in 24 countries, uh, maybe there's like a tricky tax question or something like that that the smaller model doesn't really have a great answer to and it reaches out to something like a fable class model for help.

Grading is another good example of this. If you start your work up front and provide a rubric of what a good outcome looks like, then you have an executor agent and you have a grader agent. The grader agent is checking whether the executor did a good job on its work and telling it to iterate until it gets the work done at high quality. And then lastly is dreaming. Dreaming is like, so when you run a single agent, it's writing to memory, right? It's like choosing to write to memory assuming that you've turned on memory and then it can use those memories later. Dreaming is when you look back on all the past sessions and aggregate new memories that you add into memory based on kind of the aggregate of all the work that was done previously. So maybe one way to think about this is like if we're doing 24 countries, the agent is working through like one, two, three countries, maybe by the third it's got some aggregate learnings across those three countries that it adds into memory to do the rest of them even better.

And so we ran some experiments to see, uh, does, you know, does this actually hold, like do you get better outcomes if you use multi-agent strategies where your tokens have specific jobs? Um, and this is from back in July. We ran this with, um, Opus 4.8 and we took a bunch of complex financial tasks and we said, 'Okay, how many times on average does it take to get a perfect score on some complex financial task if you keep the budget constant and use each of these different strategies?' And we found, uh, that every strategy besides just pure execution, um, gets better outcomes. So this is really cool, but when you're like, 'Okay, great. I'm like designing a multi-agent system. I want to get hard work done,' you're not necessarily spending the time up front to say like what should my multi-agent strategy be, right? Like you just want to get work done. So the obvious answer to this is let's let Claude decide what its multi-agent strategy should be.

And so we have, um, dynamic workflows. We launched dynamic workflows in cloud managed agents last week. This is brand new. Um, and it's exactly what it sounds like. Claude upfront when it starts a task decides, um, you know, what should my plan be? It writes a plan, um, like a deterministic plan that its agents will follow. Um, and then, uh, it executes many, many agents in phases in order to get the work done. Um, and noting that this is complementary with Versel workflows. Versel workflows kind of sit a layer up. It's like code that sits around the agent to make the system more deterministic. Whereas dynamic workflows within cloud managed agents is the agent kind of orchestrating its own work within the non-deterministic part of the system.

And so you might ask like why not just one agent with really, really, really long context? We are working on giving you longer and longer context, um, to work with Claude. Um, but at a certain point that starts to run out for a few different reasons. Um, like one, you kind of start to run into laziness. I'm sure a lot of people have felt this when they're working on like pretty long-running tasks with models. Um, you know, maybe out of 24 countries you get to the 19th country, you're compacting, you're following all the best strategies, but at the end of the day the agent is starting to, uh, exhibit, um, what we call laziness, which really just means like it's not like taking the actions that you wanted to take because of stuff like context rot over time. Um, another thing you might see is like if you have one single agent that's like deciding about its own work and whether it was good work, um, the agent likes its own work and so it thinks its work is good and you probably want a separate agent to be grading the original agent's work. Um, and then lastly there's just goal drift, like after many, many hours and tons and tons of work the agent kind of loses track of what it was originally trying to get done.

So with dynamic workflows, our, um, kind of hero example with this, we took a huge codebase and we planted 70 bugs in it and we told Claude, 'Go ahead, run a dynamic workflow to find all the bugs.' It tried three times and in each of those three runs, it found 66 out of the 70 bugs. Then we took that same codebase, the same 70 bugs, and just three times we gave a single agent just like go at it and find the bugs. And in each of those three runs, the agents found anywhere between 14 and 27 of the 70 bugs. So really what we're seeing is just for like really, really highly ambitious tasks, a dynamic workflow, uh, just performs a lot better than you would see with a single agent trying to get work done.

And so with dynamic workflows, you'll find the agent will choose between a few different patterns and mix and match these patterns. So it might choose to fan out the work and then re-synthesize at the end. Um, it might do adversarial verification where maybe it's like you're doing a legal task and a second legal agent is like poking holes in the first agent's work. Um, and then you've got just kind of like looping until done. That strategy I talked about earlier where you define what good looks like, what a good outcome looks like, and, um, you kind of check and make sure that you're actually getting that and continuing to iterate if you haven't gotten that good outcome yet.

So, let's go back to our example. We're launching in, uh, 24 countries. Um, and in this case, if we're running a workflow, Claude decided, um, to write a seven-phase plan. Um, so it's going to plan, it's going to do research, it's going to draft, it's going to review, it's going to fix, and then it's going to write a report. And it's going to do that across, um, all of these seven functions in all 24 countries. Um, and so this here, it's just started out. One thing you'll note on here is session budget. This is a hypothetical UI, but you'll notice session budget on here. When you are running these workflows, they can be really token hungry. Save these for your most ambitious tasks. Um, but you can set a budget and make sure that Claude, uh, does not kind of blow through the amount of money that you want to spend on that, uh, that task.

And so here we have it done, right? Like maybe it, uh, chose in some of these phases to like fan out and come back in. In some of these phases, it probably did some adversarial verification. It looped all these sorts of things. Um, and it gets all the work done and it uses 81% of the budget. For context, dynamic workflows can run up to a thousand agents. Um, so these things can really take on a lot of work all at once. Um, about 64 of these will actually like execute work at any given time. Um, and again very token hungry. So best for your most ambitious workloads.

Okay, so now you've got an agentic system on, uh, a Claude brain, Versel infrastructure. You've made it really, really powerful with really, um, intense multi-agent strategies. Um, but that is, uh, not exactly where we want to be unless it's a really, really, really secure system. Especially when you're running so many agents, you've got to make sure that bad things aren't going to happen. This is something that's really front of mind for a lot of people. So let's spend a few minutes on security.

So the way we think about agent safety at Anthropic, we've broken it into these four buckets. The first one is model alignment. Um, we're spending a lot of time and energy training Claude to be good and make sure that Claude doesn't do bad things. Um, this is, uh, our, the entire mission actually of our company is making sure that agents create really great and safe outcomes in the world and not bad outcomes in the world. Then we've got safeguards. So the first thing being online safeguards as tokens are streaming through our API to you. We're running classifiers to make sure as best as we can in real time that, uh, again, good things are happening and not bad things are happening. You may have experienced in the past like, you know, you're working on something related to cybersecurity or otherwise Claude might have refused to help you, um, because it's not sure whether or not, um, you're doing good work or bad work. Um, that's something that we're working to make a lot better over time. Um, but that's those online safeguards that are triggering in real time doing the best that they can to figure out whether something good or bad is happening.

We've got offline safeguards for our, uh, most powerful, our most intelligent models like the fable model class. Um, we are making sure that we're able to look across all sessions and, uh, do some automated review and make sure that some of the things that would be hard to catch in real time are things that we're able to catch and make sure the agent is doing good work. So all these are things that we're spending a lot of time thinking about. But this last category, this is an engineering problem. Agent infrastructure is an engineering problem and it's really a shared responsibility. It's us, it's Versel, and it's really all of you who are building and running agents to think really hard about whether you have the right infrastructure set up for your agents to be secure. So, let's talk about this last part.

So, the first piece here is, um, the architecture that I talked about earlier with cloud managed agents, keeping your brain and your hands separate. This is one of the most important things you could choose to do from a security perspective. And the easiest way to think about it is actually to just assume that everything below the dotted line here is untrusted. And so if Claude is writing code, it's choosing to execute work, it's choosing to call tools, all of that will happen down at the sandbox layer. And you should assume that nothing in there can be trusted. Which means that if you're like, let's say you've got logs running, right? You're monitoring what the agent is doing. Don't let that stuff touch the sandbox because Claude could write code to change its own logs and mess with your monitoring of what's happening. If you've got a kill switch to make sure that the agent's not doing anything bad, that should be nowhere near where the agent could choose to actually execute untrusted code and like literally kill your kill switch. Um, so this kind of brain-hand separation is something that we think is really, really important for, um, security purposes.

And one of the most important aspects of this is making sure that you never have credentials go inside your sandbox. And the way that you can pull this off is with Versel sandboxes, you have a sandbox firewall and that should be the place where you choose to inject your credentials before you go out over the internet. So what do I mean? It's like let's say the agent is choosing to call an MCP server, a tool over an MCP server, maybe it's, um, you know, hitting an API or a CLI. The code that Claude will write should have basically like a fake token, like a placeholder credential, and then only once you get to the firewall should you inject those credentials before you go out over the internet. Um, and so this is something that Versel supports out of the box. It's called credentials brokering. Um, and something that we feel is one of the most important things that you can do, um, to build safe agents. And so if you're building an agent where you've basically just like taken the entire agent, shoved it in the sandbox, you're like automatically breaking this rule. And so this is why that kind of pulling apart brain-hand architecture is really important.

And then we get to just best practices around sandboxes. Um, so you've probably heard a lot about sandboxes lately, the different types, um, of sandboxes from containers all the way up to dedicated hosts. And the differences between these different sandbox options is really the level of isolation that you have, um, and whether it's weak isolation or strong isolation down at the level of the user kernel. So what we tend to recommend are microVMs. Um, whereas like a user space kernel option is something like gVisor. Um, where, you know, you've got kernel separation but it doesn't have this like actual hardware level, uh, separation like, uh, you know, making sure that, uh, you don't have like tenant issues there. This is something that, uh, Firecracker gives you out of the box. Um, and Versel sandboxes run on, uh, Firecracker microVMs. Our sandboxes do the same. And this gives you what we think is kind of the best, uh, middle ground between isolation but also fast startup times and, um, the ability to like spawn these things pretty quickly as you need them.

And so then we have, um, egress controls basically deciding like what can the agent go do out on the internet? And the best practice here is really just like deny by default. If your agent doesn't need to do anything over the internet, don't let it do anything over the internet and choose to fully lock down egress. But, um, if it does need to do things over the internet, you should just have an allow list. You should figure out what are the things, where are the hosts that you might, um, want the agent to be able to interact with and you can configure those and make sure that those are the only places that the agent can go and, um, interact with.

Um, and then of course lastly you've got monitoring and your kill switch. I touched on these really quickly earlier. You should have monitoring. You should make sure you know what your agent is doing. Um, and you should have a kill switch. All these things come out of the box with both cloud managed agents and Versel. Um, really easy to configure and you should just make sure that you are taking advantage of them.

And so, uh, if we go back, um, to our crazy, uh, task that our COO gave our agent, um, the work got done. We've gone through 24 countries, um, across all seven of those functions and we've got a plan, uh, that is ready to review and, um, your crazy COO can hit that one button and launch in 24 new countries.

Uh, and the last thing that I will leave you with, um, this is new for us as of last week. If you have a Claude Max or Team plan, these plans now come with API credits. Um, which is something we've wanted to do for a long time. Uh, API pricing is something that, um, you know, can feel like a lot and can, can tend to deter people. And so we want you to feel like you can get started building on the messages API or building on cloud managed agents. And so, um, you now get API credits with your Max and Team plan and you can use this QR code to go ahead and, uh, learn how to claim those. Um, and thank you for having me.

All right, everyone. That was phenomenal. We have a stacked second half of more presentations, but first, let's go ahead and get some food. Lunch is at the food trucks outside of the palace. Please exit through these doors right here. Grab something to eat, go meet some people, talk about what you've learned, and we're going to be back at 1:15 with a stack show. Thank you guys. See you there.

Afternoon everyone and welcome back from lunch. I don't know about you, but me and my personal agents were planning my vacation after this conference. >> And speaking of personal agents, Muse.AI, the website powering the personal agent for everyone and everything is actually powered by Versel. >> Pashant from Meta is sitting down with our chief product officer, Tommo, to talk about building at scale and how it can be adapted for agents of all shapes and sizes. So, please join us on stage, gentlemen.

Thank you. Hello. Hello. Wow. Welcome back from lunch everybody. I hope you're enjoying Ship SF 2026 here at the Palace of Fine Arts. It's been an awesome day so far. Um, I'm excited to be back on stage with you this afternoon, uh, joined by a dear friend and, and former colleague Pashant from Meta. Um, Pashant, I just want to get right into it because I know we have way more than 20 minutes worth of content. Let's do it. Uh, we have some meaty topics to get into. The first one is this. Look, 18 months ago, I think many of the people in this room, many, much of the world sort of wrote off, uh, Meta for the frontier race. Um, and then Super Intelligence Labs was, was born, Meta Super Intelligence Labs, and today, you know, I think you guys have sort of catapulted to the frontier space and are a serious player. So the question is, what were the decisions that changed Meta's trajectory in this space?

Yeah, I think, uh, the topline answer I'd give on this is just a relentless focus on velocity and the, and the pace of innovation that, that was like the underlying principle, uh, when Mark and Alex and, and Nat Friedman started thinking about Meta Super Intelligence Labs and most decisions that we made since then have been made with that as the framework, uh, velocity over all else. Um, there's a few factors that go into increasing velocity. I think one of the early decisions that we made was, uh, to keep the team really small. Um, Meta Super Intelligence Labs is a famously small team and that's just not the people who actually build the models. It's also the people who build the products, the API and everything else that we put out there. Uh, and so that decision to make sure that we wouldn't scale out the team but would actually scale up with people was the underlying bedrock of the, of the first set of things.

The second thing was the people that we brought on board. Uh, high agency people, extremely autonomous. Uh, and the second key decision was that we're going to trust the engineers. We're going to trust the researchers to make the decisions that matter. Um, so now you've got the small team, um, highly, you know, high agency, very autonomous, great judgment, and that sets the first set of principles. Now you've got that and you need to make sure that you reduce and eliminate friction in everything that they do. And I think that's partly why I'm on stage with you today because one of the things that you sort of have to decide is if your own infrastructure doesn't work for you and you want to work really fast and you need to adopt something that's amazing and it's good and it helps you iterate faster. There are no sacred cows in MSL at all. We will adopt whatever infrastructure helps us move as fast as possible. Whatever technology helps us move as fast as possible even if it wasn't built by Meta.

Um, the second thing that I would say is that you have to be very mission-driven about this and I think Mark stated our mission pretty clearly. Uh, we don't believe in centralizing, uh, super intelligence to very few. We believe that this will be great when we distribute it widely. Uh, and we give, uh, people the authority to direct it, not us. Um, that's partly why we've been doing open weight models. So, uh, we announced Glimmer earlier under an Apache 2.0 license and I think everybody here has been at the VCEL Ship event. Uh, but we just announced, um, new Spark Open this morning. I'm hoping you guys get a chance to try it out and we really want to ensure that everybody has access to super intelligence and that it's not bottled up and we're not the only ones who have access to it. And we did the same with Muse. Uh, Muse is a product that we put out there. Uh, we definitely have subscriptions, but it's very important to us that the vast majority of people in the world use Muse over time because everybody in the world deserves a personal agent, not just those that have gotten used to it.

Look, the thread through all of this is velocity. It's velocity and access. Um, and as you, it's, it's the pace at which we can push the frontier of intelligence forward. But then more importantly, if you push the frontier of intelligence forward, what can you guys do with it? And so we really believe that we need to make invention possible. And so you combine really great people, good judgment, remove friction, and then give them the tools and then give them an empowering mission. Uh, and magic happens. And so we've done what, 11 models and products in the past, uh, since April. Uh, and we're not stopping. I'll be back next week and the week after because we have an incredible team.

Amazing. Shameless plug. Both Muse Spark Open and Muse Wonder available on AI Gateway right now. So try those models out. Give the team feedback. We want to hear your feedback, too. Um, but I love it. I love all this. I'm, I'm really glad that MSL found Versel, and I'm really impressed by your team's ambition. Sort of operating like a startup within a startup, it sounds like. Um, Muse went from non-existing to being at the top of the app store and one of the fastest growing apps of all time. Um, you ship Muse Spark, Muse Open, Muse Code, Muse Wonder. Um, and, you know, you guys seem to be actually moving really, really quickly. Uh, for the builders in the room, how are you thinking about what is possible today compared to what folks could have built on top of your tech even just this past summer?

Yeah, look, we've been building really, really quickly. Um, I think Muse Wonder, which we announced on Monday, is, is really a labor of love. I think there's two pieces that we've really invested on in that model. Uh, we call them active memory and active focus. Uh, if you're going to build agents and you have long-running agentic work, two things that are really important is the ability for it to retain context over turn, over minutes, over hours, and now over days. And so the ability to retain this context and call back to it. It's probably one of the most important things when it comes to agents. That's active memory. And the second thing that's really important with agents, um, frankly with great employees or great builders, is persistence. It's persistence to try and find the answer. Um, Muse Wonder is one of the most persistent models that I've ever used in trying to get to the outcome that you give it in a safe way though. Um, so that's sort of active memory and active focus with Muse Wonder I think have been pretty transformative for us as we've been using it.

Uh, in what we use it in Muse Code. And so Muse Code is another, uh, CLI that we built. Um, we had it in beta and now it's, uh, available which really uses Muse Wonder to the max because it uses isolated work trees. It can do work in parallel. You're not on a single agent stuck bottlenecking your terminal. So I really think this combination for the folks that are really focused on the agent space and really focused on this idea that we can build over hours and days, uh, is truly, truly meaningful. Um, the second thing that I'd say both with Glimmer and with, uh, our open models, we've really opened the ability for the builders in this room to build locally. And so we just partnered with Apple. Uh, Muse Open actually, MSpark Open runs really well on a Mac Studio. Uh, this was a collaboration that we did with them and this was part of like putting intelligence in people's hands and making it local, not just locking up behind a cloud. I think those are the two things again, the same theme, access. Everybody should have access to this and this notion that we need to be able to do long-running work. Um, that's, that's, that's what I think you can do today that you couldn't last summer.

Yeah. And I, you know, in, in terms of the things that you guys have shipped, I'm really proud that like meta.ai, Muse.ai, these things are running on Versel. Um, and you talked a little bit about this at the beginning, but I, I just want to hear a little bit more. You know, take me back to this sort of week that you guys decided you were going to take a bet on using Versel. You said no sacred cows. Bring us back there. You know, what was the team debating? What were you deciding? How did you, how did you make that decision to use the same Versel that anybody in this room could use?

Yeah, the honest answer to this one is much like many things at MSL, it started as an experiment, not a top-down decision. A small group of engineers was iterating on a website and they chose Versel. Uh, they were finding it really good. Um, I think I remember the weekend when, you know, we were working on something and someone called me and they said we need to make this change and I said this sounds amazing, we need to push it out. And I said so is it out? And they said, uh, yeah, you know, uh, six hours. Uh, and I lost my mind because, you know, we were trying to iterate really quickly. We have this lean team. We can't be iterating on six-hour periods. And that's about the time that this experiment became reality for us and we started iterating on Versel.

The reasons are pretty clear. I think, I think the folks in this room are very familiar with Versel. For us, it was initially all about the fast deploy and being able to iterate as quickly as possible because the six hours was not going to work. We wanted hot reload. We wanted minutes. We wanted to move very quickly. And the second thing was the rollback because if you're going to roll back, uh, you need to be able to take more shots on goal. You're going to make some mistakes. You need instant rollback. You need to be able to iterate quickly. You can't be worried about some bug that you would in production, especially when you're running one of the biggest, uh, sort of AI chatbots/agents in the market.

There were two other things that I think are deeper. Uh, and the first I think for us was really about the fact that Versel is in-distribution for agents. A lot of what you've done with Next.js, TypeScript, Tailwind, this is stuff that agents really understand well. They don't necessarily always understand proprietary stacks. They've gotten better over, on out-of-distribution work over time since that period. But this was definitely an asset because we were heavily using agents to build Meta AI at the time. Um, so this was really important.

The second thing is again this idea that we have at Meta that we need to make invention possible. And so what I started seeing when we started deploying Versel is that it got out of the hands of the engineers. Uh, here, here's a famous stat that I'll give you. The engineering manager on the team, uh, writes is number three in the total number of diffs or PRs because they got so adept at using agents and particularly working with Versel. I'll give you some more numbers which is from the time that we decided to do this, we must have written over two million lines of code. It took us 95 days to get from we are deleting everything and starting from scratch to being there deployed in Versel. That's when we launched Meta AI in April. And then that's, that, that this engineering manager was third in the number of diffs and that designers were shipping and they were being able to iterate on VCEL. That then became the deeper reason which is like we can make invention possible with this stack. So it started with deploys and rollbacks and all the reasons that we would want to adopt VCEL. Uh, but I think we found it was really good for agents and it was good to like open up and democratize the code. Four engineers went to what, 97 engineers in the space of three months working on that codebase. Uh, and since then we've been partnering on a bunch of stuff. It's been great.

You know, you mentioned agents choosing Versel, and I think there's a lot of history there, right? Versel's been around for 11 years now, and I think in the early days, just making the developer's life easier and making it so that folks that didn't want to manage infrastructure, didn't want to think about it, didn't have to. Um, that resonated with a lot of folks. We could framework-define infrastructure our way to global scale and performance and all these things. Um, and it turns out that the optimizations that we made to manage infrastructure also really work very well for agents. So I'm glad that, um, there was some organic growth and adoption there internally. Um, and I'm glad that, you know, the agents still seem to like Versel. Um, one of the things that I've loved though is that, you know, we're not just building Versel for developers.

anymore. We're now we're building it for true serious enterprises. And you guys are about as serious of an enterprise as it goes in terms of your scale, your security requirements, governance, all this stuff. And I've loved working with your team because you've really pushed us to, you know, expand the needs, the capabilities of our platform. And I don't consider you guys just a customer. I consider you a true partner. And from your perspective, can you share with the room like where you think you've pushed us at Vercel the most and, you know, what that looked like?

Yeah. At Meta Connect, I told the world that, you know, we want Meta to power your most critical workflows. And I think that's what we wanted from Vercel. That's what we needed you to be at, and that's where I think we pushed you the hardest. Look, early on it was pretty obvious that what you'd built wasn't actually built for a company like us. The whole stack was engineered around speed. It was engineered around a startup. But we have privacy and security requirements as Meta that we take extremely seriously, and these are the hard ceilings that we simply cannot cross. And there was a great deal we could build on Vercel, but there was a great deal we could not build on Vercel at that time. So, two concrete walls. One, our code running under your account on your infrastructure with our user data is a hard ceiling. Number one, that's like a non-starter. It's completely non-negotiable. The second was that Vercel actually as an app had no path into Meta's internal infrastructure. So when we were iterating on Vercel, basically the workflow became that every engineer was sitting there and like writing these REST endpoints so that their Vercel app could get to it, and that was killing all the benefits we were getting of the deployment speed because god forbid you had to break that contract or you had to make a different, you know, choice on your back end. My deployment speed was back to the hours that it was before, and that was immensely frustrating. So those were the sort of the two walls. You know, we had hundreds of these call sites. So I think we came to you with something fairly audacious. The history is lost on whether we thought of it or you thought of it, but you were very, very open to it for sure, and I think you had it running for a while, and it was let me run our functions inside our AWS accounts. So you keep the routing, you keep the developer experience, but we want our code to be secure. We want it running under our account. We want it running, and that's what I think we call bring your own compute. Now you guys announced it this morning. I think that's broadly available now. And all of this started as a document. I think it started on some channel. It didn't start as a product saying, "Guys, is this possible?" And I think that's what's been great about the partnership with Vercel because they showed up not as a... it didn't feel like a procurement conversation, you know, it wasn't about the deal. It was about us co-building this thing.

That's right.

Because it was like really important for what we wanted to do. And I think it aligned with your ethos in a big way as well. We did this, we launched it internally in like these internal development tools. Then we launched it in Meta AI. Then we launched it in Meta Studio, and now we use it in dev.meta.ai. So the AI sites are Vercel sites, and a large part of this has been what we've done. So our engineers can do this privacy-aware stuff. Vercel has no access to Meta's infrastructure. It's running under our account, and we still get the fast deploy. So, what's not to like?

That's great. Yeah. You know, for a very long time, many of our customers would ask us about this very thing, and we would say, you know what, we've been wanting to build this. Why don't you be a design partner with us? And they say, well, you know, let us know when it's ready. Actually, we'll just use Vercel as it exists today, but if you ever have this available, we would love to buy it. And then you guys came along and you said, no, let's build it together. We will absolutely be your design partner. And you pushed us in the best way possible, and it really felt like a proper collaboration. And not just on that, there's a number of other things we've worked on together, and so it's been a great collaboration. Thank you to you and your team. And I'm actually inspired by how quickly you guys are moving inside of Facebook. It's always been about move fast, but it seems like you guys are moving faster inside of a move fast environment. You know, clue us into what you think the future holds here, not just for Meta Studio and the tools, but for Meta Superintelligence Labs in general, and maybe more broadly speaking for Meta in general, wherever you want to go.

Yeah, look, our mission is to develop personal superintelligence and give it to the world. Meta Studio is obviously the centerpiece of that strategy for us. It's a core part of what we're doing here. Everybody deserves their own agent. We want that to be Meta Studio. And I think the other bit is that we really want to make it possible for the builders in this room to build. And so you're going to see us push that really hard. There's a few things that I'd give you as advice just as you think about building. The first that I want everybody in this room to think about is the time has come for us to stop building for humans as the main demographic that we build our code bases for. Build for agents. Choose the stack that is optimized for agents. They are the ones writing the majority of the code. Some of you are going to rewrite your code bases 10 times this year. I promise you, you're going to throw it away and you're going to rewrite it, and you're going to have the courage to do that because it's possible. So, you know, stay with these in-distribution frameworks. Really build your code base for agents, and frankly even start building the products that you're building for agents because this is something that you're going to see over the next year. That's at least my belief that we're going to have more economic activity, more building activity, more commercial activity, and more personal activity driven by these agents. And each of you will have several. Hopefully, one of them will be Meta Studio. That's what I would hope as well. The other bit which I think is something that we're all working through as an industry is that one of the things that we still haven't gotten right is that everything is like a web-shaped request. You know, it's like a request-response model. Agents run for hours. They maintain state, they maintain context, and I don't think any of our infrastructure or how we built stuff really is suited to that long-running work. So that's something we're going to push really hard on, and something I encourage all of you to do as well. But we're going to just keep taking shots on goal, and you should too, because there's going to be a lot of hits in the coming years.

Pashant, incredible conversation. Thank you so much for being here and joining us today. Thank you everybody for joining us. Have a great Vercel Ship.

Awesome.

Thanks, brother. Good time.

Melky, quick question. How many unread Slack messages do you have right now?

Uh, let me check. About 149, but thank goodness my agents are on it. So, we... Oh, actually, make that 150. G just pinged me. Uh, give me a sec. I'm going to set my Vercel agent to actually take care of this. I think you could, you got this.

Okay. Well, Vercel built our own internal agent V, trained and onboarded like an employee, grounded in Vercel's own data, and of course secured end to end through Vercel Connect and Passport. Mala from Slack and Matt Lewis from Vercel are going to join us now on why they put V in Slack specifically. As you can see with Melky, the agent should live where the work is actually happening, and for us that's Slack. So please welcome on stage Mala and Matt.

Hi everybody. I'm Matt Lewis from Vercel, joined by Mala from Slack. I'm on the partnerships team. I work closely with Slack every day. And if you were here last year, I gave a talk called Agents at Work. We started with a simple idea. We wanted the agent to join us where we were working, and we wanted to bring it into the channels and threads that the work was happening. I'm having a bit of a difficulty getting the next slide to come up. There we go. And like I said, last year we brought agents to work. Work starts in conversation. We wanted agents to join the channels. And that's exactly what happened. Everybody at Vercel started building an agent. Are we having any issues with the clicker? We built an agent for data, an agent for docs, an agent for sales, but they kept compounding. We had agents living everywhere throughout the business, but they weren't working together. And to fix that, we built one place for them all to live. We called it the internal agent hub. But we didn't listen to our own advice. We built a web app where all of the intelligence, all of the agents lived. And it wasn't multiplayer either. This meant everyone had a single-player conversation with the agent. It wasn't where work happened. Mala, is that clicker working for you?

There we go.

Like I said, we made people come to the agent. We ignored our own advice. Now, Slack's been doing a lot of work to make Slack the home for all of your agents. So, Mala, why don't you show us what your team has been working on?

Yeah. Awesome. Thank you, Matt. So, I love this story because it's a lesson that we keep learning. The question isn't whether or not you can build a good agent. The question is whether or not it meets you right where work is happening and also has all of the context that it needs that is unique to your business needs. And so, this involves bringing three things together: your people, your agents, your platforms, all connected in one place. Now right now these often live in disjointed systems and separate silos, and employees are expected to manually bridge the gap between them. This can be obviously a huge productivity drain, but more importantly it's also a big adoption hurdle, and that is where Slack, your work OS, can come into the picture, where your files, your conversations, your agents, your decisions are all sitting in the same place and meeting your teammates right in the flow of work. So there's no separate app to have to go to. There's no context to relearn. This is where true multiplayer agentic collaboration can happen. All righty. So what does that look like in practice? I want to walk through an example of exactly how we've made it easier for agents and humans to collaborate in Slack. So this is an example of a conversation that can happen in Slack of updating a web page with a video link. Anyone on the team can tag in a coding agent right in their flow of work. And in this case, the coding agent spins up a code channel and brings with it all of the context from the previous thread and the conversation. It gets to work and realizes that it is missing the video link that it needs to embed. And so Alan ends up tagging in his marketing partner Ash to give him the information. Ash comes in, gives the information, and carries on with his day. From here, the coding agent picks up right where it left off and makes the change. And right in this view, the team can collaborate around the code diff and see what changed. Alan ends up tagging in his technical lead, Chris, to take a look and make sure things look great. Chris realizes there's a few bugs, some issues with the hex values, and so he goes back and forth with the coding agent and collaborates on the change. Meanwhile, the rest of the team can preview the changes in this HTML artifact again, right in the same view, and make sure that everything looks just perfect. Now, we can soon create a pull request ready to be merged. And all of these changes are just about ready to hit production. So, it's that quick and that simple. On top of this, this channel will be auto-archived. And because this is Slack, anyone who wants to understand the contents of this channel or understand why certain decisions were made can come back, say, a year later, and can search the contents of this channel. And I think that's a really great example of just how working this way can allow context to compound over time. Okay, so what you just saw was an example of the start of a flywheel effect in Slack. When teammates work this way and they work out in the open with each other and with AI and with their agents, something really great happens. Context naturally compounds. And this shared context makes for just better agentic output overall because it's grounded in true work. It's grounded in actual work and real collaboration. And on top of that, working this way allows teammates to build trust in each other, but it also allows teammates to build trust in their agent. And I think this is a great benefit for the org overall. So, to talk a little bit about the team at Vercel's experience with all of this, I'm going to hand it back to Matt.

Thank you, Mala. So, like I said, at Vercel, we had agents everywhere, and we needed one to rule them all. So, I'd like to introduce you all to V. V is the entry point into all of Vercel's intelligence and all of our internal sub-agents, and most importantly, it lives in Slack. So everyone at the company has one place to interact with Vercel's superintelligence, or Vercel's internal company agent. So let's talk a bit about how did we build V. Like I said earlier, we wanted the DX of a monorepo. We wanted everyone at the business to be able to focus on what they know and ship an agent that focused on their work. So the first thing, it's built with Eve. If you're not familiar, Eve is our open-source agent framework. And this is what allows everyone at Vercel to work with the same primitives. It allows teams on separate sides of the company to work independently but still be able to compound on each other's work. Second, oh, let's go back one. Independent deployments. So, this means not only can teams work independently on the codebase, but they can ship their agent independently. If we can go to... There we go. So each specialist ships independently. Every team can work autonomously. The same way that you can have asynchronous conversation in Slack, now we can all work autonomously but together. Finally, this is what allows our intelligence to compound. This is what allows all the teams to work on what they know best, both our engineers, our citizen developers, the people closest to the work, but we're still all contributing to the same codebase. Second, we use Vercel's AI Gateway. So, this is one token. If we can go one more, there we go. So, any model, so V can use any model. It can pick the right model for the job as well. A recent example of this, so Jev from Typesafe AI came out within a day. It was on the Vercel AI Gateway, and we were able to take every message that V had and instantly classify it. Is this a simple request for documentation search? Is this a multi-turn in-depth research question? And we could choose the right model for the job. That decision was able to move from the build time to the runtime. So, not only did we get better outputs from V and its sub-agents, we also were able to decrease our token spend. We were able to choose the right model for the job. And since we used one gateway, we had one place to observe all of this. If you're going to deploy an agent company-wide, you definitely want to be able to see where all the tokens are being spent. You want to have control over how they're being used, how much of them are being used. And within Vercel, we have that one shared observability and governance layer. And finally, one of the most important things is we are free to move models. All of the hard work we've poured into V, we own. We own the entire stack from the framework to the models to the tokens to the sandbox. We are able to choose a model without losing any of the work we've done. So we have the conversation history, the memories, all of the personalization, and if we switch models, it comes with us. Now finally, it had to be secure. So like I said here, secure by default. The number one thing, no static tokens. That meant that we had to be able to interact with the different parts of the business, the databases, tools, documentation, but we could not give it one static token that had access to everything. Second, channel-scoped responses. So since V was in Slack, it wasn't just about who was asking, but where was this information going to go? We had to be able to decide, even though Matt may be asking a question, is he asking a question in a public channel, a private channel, a group DM? And then finally, every turn had to be auditable. If you've deployed an agent to Vercel, you know we have a full observability suite where you can look at every turn, every token, every question. So you have full observability into what the agent is doing, and you can also evaluate how well the agent's performing. Now let's dive into, if we can go back one, a typical request. Hey V, how much did... we can go back to that question. How much did customer X usage grow last quarter, and why did their bill decrease? Now if we walk through this request, I want to highlight all the things I said in the previous slides. So first, Slack sends a webhook. For every @mention of an agent in Slack, we receive a webhook, and Vercel Connect is the front door for that request. The webhook, the signature is verified by Slack Connect, and then it enters into V, or what you could call the application layer. And like I said, V reads two pieces of information from the webhook: who is asking and who will see the response. This shapes the access and permissions for the rest of the conversation. So V is then going to route to D0. D0 is our data specialist, built and maintained by the data science team at Vercel. One of the most popular agents that we built, also one of the first. And when V routes to D0, that information has to move with it. Who is asking, where's this information going? Because with Vercel Connect, I can mint a token on demand to query Snowflake. I know, hey, this is Matt Lewis asking, and he's asking in a public channel. So actually, instead of Matt Lewis, who may have elevated permissions, we're going to mint a token with a fallback scope. We're going to basically mimic the access every Vercel employee has. That way, when this information, this response from V goes back to the channel, it does not matter who can see it because we've scoped the access appropriately. Now D0 is going to give us some data. It's going to execute a tool called a tool call to read from Snowflake. This token that we just talked about is short-lived. It's going to expire. We have full observability into how it was used. But V is going to decide, hey, you know, this is just some raw data from a database. I don't think that's the best response. I'm going to route this over to Penny. Penny is another one of our sub-agents at Vercel, built and maintained by the finance team, specialist on all things billing. So, Penny loads the appropriate skills. These skills are built by the team, the specialists, the ones that know it best. And that data that we got from Snowflake, Penny is now able to turn into real business insights. Now, finally, V is going to get both the responses from our sub-agents. It's going to combine those. It's going to answer the question. And the last piece is Connect once again. How do I get permission to write back to Slack? How do I make sure this agent is not just always able to read my conversation or write to a conversation? On-demand tokens minted with just enough scopes to get the job done, with full observability. They're not static, and they expire after a certain amount of time. So, this is a demonstration of how V is able to securely access all of our business systems. And it's an example of how the people closest to the work can write the skills and the tools needed to personalize this to Vercel's business to allow us to run our business. And you might think, hey, this looks pretty complex. If I tried to build something like this by myself, I might have to build many different primitives to get something that looks like this. But with Eve and Vercel, it really can come down to just skills and tools. It really can be that simple. The people who know the different parts of your business the best can write skills in natural language. They don't need to know how to code. They just need to know how to express their special knowledge of what they do at the business. Now, back to Mala to talk about how to get started building your own internal company agent. Oh, sorry. No, one more thing. What did we learn building V? The first thing, connections are not context. So when we sat down to build V, the first question we had to ask is why build a custom agent? Why not take an agent from any one of the larger labs and just connect the business systems? Surely it should be able to give us personalized answers for our business. But we learned connections are not context. Access lets an agent query your data, but it doesn't give it the unique pieces of your business, of what that data means. Second, traces... if we can move forward one click... forward one. There we go. So, traces are a data service. This was a big learning for us. Traditional telemetry to traditional logging. This was one V team really harped on, and the idea was that just because something doesn't exist in the response from the agent doesn't mean it wasn't logged somewhere, it wasn't in a trace. So when we were learning about this, we actually turned it into an API with Eve. So, Eve has the ability where you can set a trace policy that matches however you want to run your business. For V, this meant configuring a policy that meant output was hidden from the audience in production. If you're going to let an agent have access to your whole business and you're going to scope it properly, you must make sure telemetry follows that as well. And then finally, evaluate the whole journey. So when I sat down with the V team, they told me if you think you have enough evals, think again. While each team can be shipping independently and adding new features to their agent, you must evaluate how those sub-agents interact as well. A user does not care that the specialist did its job perfectly if the final response was impacted by another team's agent. And once again with Eve, it has a built-in eval library to make this very easy for you and your teams. Now back to Mala on how to get started.

Thank you. Okay, so with that picture painted, if you are interested in bringing your agent to Slack, it's easier than ever. We have a bunch of building blocks and tools available to you to help create a first-class experience. So we have developer tools including Slack Agent Kit, Bolt SDK, Block Kit Builder, and Slack CLI, and also a bunch of Slack platform offerings. So we talked about Slack code earlier. And we also have Slack's MCP server and client, granular role-based access controls. And also if you are interested in getting started, just take a screenshot of this. You can scan these QR codes. You can head on over to slack dev program and look at sandboxes, newsletters, and events. And head on over to slack.dev to check out blogs, tutorials, more docs, and tools. And finally, we can go back one. We also created Add Agent to Slack. So this is the easy way to build an internal company agent in minutes. You can start with a single prompt, no code, give it instructions, choose a model, and this allows you to not only create an app, but install it securely into your workspace. Now, this is how we built V. I hope you go and build your own internal company agent. Thank you guys.

Thank you.

Welcome back. requests every single day. Discuss the app-level router they built on AI Gateway, picking the right model per request in under 200 milliseconds, handling automatic failover, enforcing per-user budgets, and keeps reliability climbing even as traffic spikes. Please join me in giving him a warm welcome.

Thank you. Thank you. Thank you. Hello. Hello. Good afternoon. You guys can stay. You don't... I'm kidding. Okay, guys. It's an honor to be here. I've always been a fan of Vercel. We've been big customers since forever, even before Adapta. So, it's an honor to be here speaking to you guys. And the first thing, right, what is a Brazilian company doing here among some of the top companies in the world from a kind of underdeveloped country, at least comparing to us, right, with no outside funding and without subsidizing tokens, but getting to more than 70 million recurring revenue this year while being profitable. Thank you guys. That's right. Thank you. Thank you. And I think this graph can sum up what we're doing and how we've been able to grow so fast and so far, which is this capability gap, right, which happens since the start, since we've... with GPT-3, 3.5, we already had this gap of what the model can do and what we could do with it. Adapta has always been about closing this gap for our specific set of customers, and I want to tell you how we've done that in three different phases and where Vercel actually helped us, right. So at the start of our story, when we started growing, and what we're doing for the future, really quick. So Adapta started in 2023. The context was simple. It was like ChatGPT was blowing up, everybody was liking it, but people didn't know how to actually use it, what to use it for, what should I do with AI? That was the gap, right? What can I do with AI? It's not just a fun toy. So, we created this platform that was specific to knowledge work. We had lots of different features that we had way before even ChatGPT had them, like context building, like memory, a bunch of different prompt builders, like prompt improvements. We have a bunch of different things, and we bundled that with training. So we would not just give you the tool, but actually teach you how to use the tool, and doing also lots of educational-based marketing. So teaching you how to actually extract value from AI, and the result was great. So this is actually a picture from our first event, like we did at the beginning of 2024. We had 4,000 people there. It was amazing. In six months after we launched, we already had 25,000 customers. We were happy, things were going great. And we had even Microsoft, AWS, Google as sponsors in our first event there in Brazil. Then we started actually growing even more. So 2024, 2025, the context was what models could make was getting... like the model capability was increasing. You can do many more things with it, and model competition was rising. There's not just GPT, like Claude now is getting into becoming really good. Not even just Claude, you have Gemini, you have Grok, you have a bunch of different models, and say, okay, this is the gap. Which model should I use? What for? When should I switch? For which type of task should they use one model? Which type of task should they use another model? And we became, of course, model-agnostic. We said, okay, let users choose their preferred model if they want to, but let's build a router so we have this application which is agnostic to models. You can choose whatever model you want. And this is the platform we created. It's called Adapta One. We have that since 2024. I'll show you a quick video of how it works. So you can see you can do most of your knowledge work inside just one platform, model-agnostic. You can do presentations. You can do most of the things that entrepreneurs do, like the knowledge work you need to do, right? And that was great. So you can see we had to build lots of features for it, and the more models there were, the harder it was to negotiate with the model providers, to build versatility inside it, to commit to any actual model so we could get great price on it. So this became increasingly harder to do while we still had to do many, many different things tool-wise, on the application-wise, on the platform. So this is why... and most of all, observability was a mess. So each provider had its own dashboard, which worked sometimes, didn't work other times. Each API could have its own rules, and once we updated something in the platform, we had to update something on how we used each API. So maintenance became increasingly complex. This is why we became one of the first AI Gateway customers, which was great for us because in just one single place we could have all the things that we needed from each provider, and you could see everything inside just one place, and we could have deep relationships with just one provider, or actually the gateway, which is Vercel. So we chose Vercel instead of managing a bunch of individual deals, and that made possible for us to actually build the platform and build the router, which was even more important, so the platform could actually work. So how it works inside our platform, you can choose the model that you like, of course, but you can choose our own router. And the router, how it works, it's a step between the prompt and the gateway. So it selects automatically what is the best model depending on your prompt, on the user prompt. So if you think about it, it's simple. We gather lots of user feedback. Oh, this was good, this was not good. With it, we create what we call a golden data set. So for each specific kind of task, we can say, okay, this model performed better on this set of tasks, this other didn't. And this golden data set is improved every day. So it's always learning. It's always becoming better. And this helps us, and then we use it inside the router. So the router can decide for which model am I going to call for this specific type of prompt, which is amazing because by doing that we reduce a lot of cost while still maintaining frontier model quality. And this is just the beginning. So the results, it's not only that, but we kept growing demand for tokens. We kept growing our business. We kept growing our platform while we didn't have to think too much about switching all the time and negotiating with new model providers and actually improving the answers users get and the results they get. And of course, this has been great for us. So we improved the log token usage. Our demand increased a lot while we still decreased a lot the cost for it, the cost to actually deliver it, which is great. That's the kind of graph you want, isn't it? And of course, even better than that, our revenue keeps growing. And we're getting out to this 70 million mark, which is awesome. Even better thinking about how we haven't subsidized anything yet and we're doing it all with pure cash flow, which makes us talk about the future and where we're going next with inference, because this is what we're building now. I talk about future, but actually we're already doing this. So we're not just having a router, but actually having also our own model, of course, built on top of open source models. So what we have today is the prompt router, the grader. What we have later on, and what's already happening inside Adapta, is we have the prompt, we have the router, and then we have also our own trained model, which we already understand can solve most of the problems of the users, like a bunch of different problems we can solve it with our own model and with the same quality level. But of course, users can still choose any model they want. So we still rely heavily in the AI Gateway. And one interesting thing with this new model we're creating is that it can get better any day. Like it does get better each day, and by each interaction it learns. It is continually learning. So it's learning by every interaction the user has, and it keeps what it already knows. So it gets better every single day. And if you think about it, this is just actually the back end, right? This is how we make it work. But one interesting thing is, like I said, we're always thinking about closing the gaps, right? And which gap are we closing next? Which gap is making us possible to actually become a really, really big company and not just an interesting Brazilian bootstrap company, right? Because we do think we can get really, really big because we're doing something really interesting for our customer base. This is a new product we created which is called Maestro. So like the maestro, and it's fully agentic, right? So you can do heavy, heavy knowledge work with it, and you can create agents for your entire company inside just this platform. I'll show you really quickly also. So this is really nice. But the interesting thing is I don't think even Maestro is enough. And why not? This is a really simple graph, right? So if you think about it, on the right side, on the x-axis, we have the ticket size for a company, so how much they're spending with AI. And on the y-axis, we have value, so how they're actually getting value from AI. And if you think about it, when you look at free, like consumer or prosumer even products, you have to have PLG, right? It has to be product-led growth. There's no other way. Like the unit economics don't let you do anything else. And when you go to enterprise, you need to do FDEs, right? You have to have four deployed engineers actually sitting in the company actually building stuff for them because complexity is simply too high. PLG is not enough. So what we have is kind of like a missing middle. If you have companies with at least more than 10 employees but they're not enterprise yet, like how do you actually drive value there? And a tool, I don't think a tool is enough, and we realized that. That's why I'm trying to coin a new term here. You don't have four deployed engineers, you have remote deployed engineers, right? So instead of helping just one company at a time, we realized we can help 60 companies at a time with one single engineer, at least for our specific customer base. That's what we realized, and we're betting everything on it. So, this is another way to visualize it, a little bit more colorful, but the missing middle is that it's too complex for PLG to actually drive value by itself, but it's too small for a deployed engineer. That's the missing middle. That's the gap that we are closing. And just to make it more concrete, it feels like if you talk to any Adapta customer, it's kind of like that. Oh, it feels like I'm just scratching the surface from what's possible with AI. And we tell them, yeah, that's true, because you are just scratching the surface. You were using like a copilot, like a better Google for you, but yeah, you can have way more value with it. And just to give you, and it's a simple equation, like you have the SMB for us, usually it's a service SMB, we pack them with a remote deployed engineer, then we can drive value. Great. So just to make it more concrete, for example, Filipe is a customer of ours, he has this bottom, like he has an agriculture consultancy, and each new client, he couldn't get too many clients because it was just too much work. It was like hundreds of spreadsheets, it was a mess, and it was 100% dependent on him to deliver actual results. So we helped him create like a full agentic CRM just for him, something that doesn't exist in the world. We helped him create with agents inside. This is just a picture of it. And it was really cool because I thought it was a really interesting project. He could have never done it before. He wouldn't do it by himself, never. Because he doesn't even know what's possible. He doesn't even know how to do it. And we done it with him and inside our own platform. So this is our technology. And the results were amazing. He doubled the service capacity. He saved a bunch of money, like more than $200,000 just by the things that he used before. And he was able to extract all his domain knowledge about this specific type of service and put it into the AI. Now he can serve way more customers with the same team size, and just one simple example of what we're making possible in Adapta. So I talked to you at the start, the gap was what can I do with AI, and we developed an AI platform with knowledge work features even before the big guys here. At our growth stage, the gap was which model should I use, which tools, how to use them, and we created Adapta One and the router. And now for the future, we see that the gap is how can I move from AI personal use to actual company value, and we are closing this gap with Maestro and remote deployed engineers. So if you think about it, always the underlying idea about Adapta has been about finding and closing the gap for our specific type of customer, and each closing mechanism was building on top of the previous one. And of course, Vercel helped us actually be able to do that and not worry about things that weren't a focus for us. Right? So this is the thought that I wanted to leave you with, you guys. It's exactly that. It's what gap does your product or company need to close, and how can you close it the best way possible. Thank you.

All right, everyone. Up next, we have Sarah Sachs, who leads AI engineering at Notion, and she's joined by Vercel's own Malte Ubl. During this session, you'll hear why your work and memory shouldn't be stuck inside of one agent. Rather, it should follow you wherever you go. I'm personally very excited about this one as a bit of a Notion power user. So, please welcome Sarah and Malte.

Oh my god. Here we are. Here we are.

Uh yeah, we'll have an interesting conversation today hopefully. But uh why don't you start introducing yourself really quick?

Yeah, I'm Sarah. I lead our AI teams at Notion. Um big Vercel customers as well. So excited to be here talk about agents, building what's next.

Nice.

Top of everyone's mind.

So I at a previous event heard you talking about kind of open context. This notion of, by the way, all the time the notion of Notion, whatever, welcome to Notion, but like the notion of having some, like supplying context to an agent in a way that kind of spans multiple harnesses and agents. Let's dive in a little bit into that and tell me what you think in that area.

I mean, Notion has always been the place, our mission has always been collaborative work, right? And I think today what it means to collaborate has expanded. There's how we collaborate with each other, that's Notion's bread and butter, we'll continue investing in it. But there's green fields or yellow fields, depending on how long you've been thinking about this. There is how humans collaborate with agents, and then there's how agents collaborate with each other. And I would go so far as to say that those three collaboration types are different. But there are a lot of shared primitives and perspectives that we have that bridge those gaps. And today especially, I think that we can all say we've officially reached a state of agents for all. There's a lot that goes behind what's in your context. It's not just markdown or the context that you're looking at, right? I think that it's really easy for agents to have a scratch pad and for humans to have a scratch pad and to look at that, but a lot of how organizations and processes work, there's a huge why behind the what. Why is this information structured this way? What are the decisions that this information is used to make? What's the sensitivity to change in this information? All of that is context as well. And so what we try to do is make sure that whenever you're using an agent that's contributing or making those decisions, it's in a durable place that isn't tied to that specific harness, model, or lab. Because that's the only way that your work can persist. Otherwise, it's a state of lock-in, and a majority of our enterprise customers don't want that. And that's who we're building for right now.

Yeah, it makes a lot of sense. We have, I think, Matt talk about our internal agent V, and there was a time when we were like thinking, do we like need to build like a database where it keeps its context? And then we kind of realized it already has a Notion connection. Like that seems good enough. So I actually use, I have a personal agent that kind of has access to my calendar and my to-do list and my Notion recordings, and every day kind of tells me what I've been yapping about the day before, and it's great.

Right? I mean, our MCP has 70x'd in the past six months. 70, right? I don't think it's because humans are using coding agents 70x more. It's because coding agents are doing more, people's personal agents are doing more, their enterprise agents are doing more. And we're really proud that our MCP is the first one that all of these agents are reaching towards.

Yeah, it's actually a really good thing to pick up on. I think there's this world where many websites, apps changing who their user is from a human to an agent. The stats that we've talked about on the Vercel docs, we're now way over 90% traffic being agents. Yeah.

And I can just imagine that you're going through a similar journey where like the MCP is becoming more commonly used to do things.

Absolutely. I would say, I think I can say, I will say around half of content written to Notion right now is written by agents and MCP, and there's usually humans in the loop at some point, right? But that's an astounding number. I'll tell you an anecdote about a management mistake that I've made. You know, when I took on the search team about two years ago at Notion, we had Q&A as a product, and that was different than our search team, which was like navigational human search, right? And I said, "Come on, these are the same problem. One team, you guys figure out an interface. You have two customers, agents and humans. It's one team." I think that that was a decision that I made that actually doesn't end up being true. I think the way that agents search and look for information is different than how humans search and look for information. Of course, there are shared things like our vector indices and our Elasticsearch indices and our tokenizers. I mean, of course, there's shared infrastructure, but the way that information is consumed, the read and write patterns of that information, the type of loads and patterns of how you do like progressive disclosures and different searches, those are really different than how humans act. And so when companies are going through this transition, when they're building for agents, I think there is a design pattern that's really easy to fall into, which is to say humans work just like agents. Agents work just like humans. Let's just expand this and take the simpler functions that we have and put it behind MCP. Right?

This is actually so, like I love this perspective, very different than what I usually talk about when I think about this kind of transition towards agents as a user of applications. So this is really interesting, and I think there's a general pattern where with humans, and you know, we can nerd out about search because I used to work in that space at Google, like with humans, precision is extraordinarily important. And with agents, having high recall, maybe a little bit worse precision, it costs you tokens, but otherwise they're really smart, so they can figure out which of the information...

Ranking is totally different. Positional ranking is like the thing, right? MRR is like a super valuable, as you know, metric in building search algorithms for human consumption or navigational search. Ranking doesn't matter to agents. Getting ranking right, just like one of the things that we did when we decoupled these two interfaces is we killed a ton of ranking algorithms that just added latency. Like what is the point of doing this reranking, right? Similarly, the information that's returned. So a human usually wants to see like the snippet that matched, and they want to be able to see, and so you have to index and do snippet matching, etc. When you see ranked search results, an agent, it doesn't even need to be human readable. It could be a series of six words that don't even live together in linear order in the document, right? Because you're optimizing it as an intermediate state. Yeah, I could rabbit hole here. You can pull me out, or I can keep going. It's an incredibly deep topic, but you know, often people primarily think about, okay, I have to represent my information maybe in markdown or obviously ship maybe a...

CLI, which I think you guys have done, and seems... and then download it. I mean, I think so.

Right. I think one interesting topic when you hear people talk on X about, okay, I want to bring my own agent, which is like very reasonable, right? And so one of the philosophies that we've been following is that the Vercel agent ultimately also only uses the CLI, right? And so you keep yourself honest that you don't privilege yourself and make yourself available to the ecosystem.

Yeah. No, this is really interesting. Like, I think evals were kind of obviously a thing that we would all have to care about now in the agentic world, but now it's I think kind of really coming to be something that everyone does.

I think one technology that's super relevant there is skills over MCP.

Which is an upcoming thing and you kind of can already do. So we are experimenting with that.

Nice. Very cool.

Right. That's kind of the thing that everyone thinks about when they think about context is artifacts. But there's also skills, connections, and memories.

Yeah, I feel for anyone remotely related to my household, they're very familiar with the different agents that are running different elements of all of our lives. Kind of shifting gears, you mentioned already obviously Notion is using Vercel sandboxes. The notion that like computers are a thing that you give to agents and they operate on them is maybe a year old or we're approaching mainstream. I think it has become kind of the standard architecture. Do you see that way of building agents kind of settling down into one way or are we still at the beginning?

Do you see the architecture that agents kind of are based on settling down or are we still exploring the world?

Right. Right. Right.

So, I know you've been working on this AI thing for a minute. Um, but a month ago, we rediscovered ML classifiers.

I'm talking about Jeff. And, um, I mean, I'm a big fan. I'll talk to you on this stage actually later today, but yeah. What's your take?

Get prepared.

Yeah. No, I love that perspective. I think really like, and you can still build classifiers, but the fact that you can try whether a classifier would be appropriate in this task within one minute is a game changer because previously you would have to train it for weeks. It's so funny because um, we are partnering with these companies and I have a new grad on my team who was trying to evaluate it and he didn't know what a precision-recall curve was, which makes sense, right? Like if you're working in AI today, um, you don't really think about precision versus recall and what the decision boundary should be if you output a probability. So it is a little bit, you know, it is kind of like industry is reinventing some of our elements too. Um, but yeah, I think it's an important technology that we should juice.

Um, I know that you previously told me how like Notion is kind of looking at, okay, let's get new models supported on our system. Is that something that you still consider high priority and what's kind of the process you're following? You already talked a little bit about eval.

That's yeah, 100%. I want to highlight one thing you said because I think we have lots of startups here and maybe they want to get early access to models and I think it's a good lesson that if you have a very strong eval story so you can give good feedback, people will give you that early access because you're actually trading something incredibly valuable to them, um, that they don't have, which is your proprietary, real good eval results. Yeah. Okay, we're out of time. I have one really, really quick question. Okay. Agents have emerging behavior. Um, what's the most weird thing you've seen happening on Notion that you find exciting?

Amazing insight. All right. Thank you, Sarah.

I grew up in the cloud capital of the world, Seattle. So, it should be no surprise why I'm proud to be a Californian after six years and counting. Don't miss the rain and very grateful for days like today. Yeah, the weather's great. Ole Walle, Ole Dehan, Managing Director at AWS, the original cloud. Today, 97% of companies have developed some kind of AI agent, but very few are actually seeing transformation from it. They're going to, they're getting into that exact gap and how Bring Your Own Cloud on AWS gives teams a modern developer platform while everything still runs inside their own VPC with Vercel as the control plane. Please welcome Ole Walle to the stage.

Thank you. Thank you. Hello. Hello. I'm incredibly excited to speak today because I was thinking about the opening that Guillermo set up and it made me think about these moments. And so I want to go back actually way back to a moment that we weren't even around for. It was the Big Bang. Something happened. Then there was hydrogen, helium, lithium. That was basically it. These foundational elements and components. And off of this simple foundation, complexity grew. Planets, stars, ecosystems, living organisms. And it all happened underneath the surface. And I think about what's happening today in technology. I'm not saying it's a Big Bang moment, but I think there's something that has been brewing under the surface for several years. And when you think about this opportunity, one of them related back to what we've seen in the last maybe three or four years. I started programming when I was like in the fourth grade and I remember one of the first programming books you ever pick up. The first thing you do is you actually type hello world. It's where you started. It was static. It let you understand how programming languages actually worked. And then what happened is the web grew and this hello world was still static. It was a way that it would just serve pixels and you look at it and try to understand it. But similar to that foundation moment, something was brewing underneath the surface. And if you fast forward to 2026, hello world has started looking back. It's no longer a static page. It's an agent. And Guillermo talked about this in the opening during the day that there's so much things happening with agentic. Vercel said just six months ago, 3% of Vercel deployments were triggered by coding agents. Now that number is 60% in six months. It's the fastest infrastructure shift the modern web has ever seen. And what's really exciting about being at this conference is not to talk about just all the AWS services, but how do we help customers navigate what is this kind of monumental shift? It comes with two parts. One, the foundations. How do you think about security, governance, data and your strategy? Then it comes with the evolution. The way you work will be fundamentally different. And then you layer on all the things that are happening within AI that you then need to factor into your equation. And even though I get the opportunity to work with customers on a regular basis, what excites me is I get to see it every single day when I'm at AWS and Amazon. And you can think about any part of the ecosystem. When I started, I started in Internet of Things. Not going to call it physical AI, but Internet of Things, we were sitting there, logistics, robotics, picking, packing, labeling, QR systems and understanding. Then you get to things like smart home and Alexa Plus where it's like how do I interact whether through local systems or through the cloud. All of these things have been underpinned by AI for decades. Machine learning and AI have powered parts of Amazon, but again, it was underneath the surface built on foundations and those foundations building to more and more complex systems. And so what's great to see is how this space continues to evolve. Now you're probably one of two types of personas in the room. You're either an engineer and I'm like, 'Hey, I really want to build.' Or you're someone who's a founder or a CEO or you work in a large enterprise and like, 'How do I get my teams to operate differently? How do I better serve my customers?' And so you start thinking about these changes. If I'm an engineer, the weird thing is I'm not the one that's doing all the coding anymore. Agents are the ones who are driving my deployments. They're driving the way that I approach and solve problems. What if you're a business owner or business user? What if you're in an enterprise? Your fastest growing user base will not be a person. It will be an agent. You now have to design for two types of users at any given moment. A headless mode that can handle more context and more understanding and can go off and run for long periods of time. And a user who might have to make a very critical decision needs one or two pieces of data right at their fingertips to understand what to do next. We hold these two essentially competing positions in parallel. But what's great is that by combining things like AWS and Vercel, you can start to solve these complex problems simply.

And so I'll talk about these in maybe a few different phases and what we've kind of seen in terms of the advances in AI. The first one I want to talk about is that the economics have changed. When you were to start a SaaS company or you started a software company, you would need 500 people and your job is to get to 100 million ARR so you can go public, right? It took lots and lots of people not just to write code but to create the go-to-market, to handle the customer support, to do the sales and enablement of customers. And now you're seeing teams, four engineers, 10 engineers, 40 engineers launching and building sustainable businesses leveraging AI. They're not writing the code. They're generating it. They're steering it and then orchestrating things. And it doesn't take going too far back in time. I won't go back to the Big Bang again until the end, but I can only go back to 2023 and it was interesting. You would go talk to some customer somewhere, auto manufacturing or retail, and what would they say? 'Oh my goodness, AI is coming. I'm going to do a chatbot. This FAQ is not interesting enough.' And they were simple use cases, one maybe 2K tokens, a little bit of context, but they had to start somewhere. Simple, easy to understand. And then you go into 2024 and 2025, this is where you started seeing co-pilots. 'Look, I need a little bit more context. I want some human-in-the-loop behavior.' You're probably one monolithic agent that has a lot of essentially subtasks you can orchestrate, but you're going to use a little bit more tokens in space, five, 15K tokens. And now in 2026, we've seen this essentially expand pretty exponentially. And these are just some statistics, but essentially for an agentic system, an agent running, you're going to have 50K tokens. But what happens now? Multi-agent orchestration, maybe a manager agent with sub-agents, maybe teams of agents orchestrating, then coalescing a response, then going off and doing work, doing reflection to understand if the quality of the answer is good enough to move it forward. All of this happened essentially in the last few years, taking these foundational building blocks and being able to rapidly create something complex but treat it simply. And so what's interesting, we say if this space is moving faster, how do you continue to differentiate? What makes you have a compelling offer? And what I tell customers is this a little bit of a flywheel. One, they're just better and better models. Models drop every single week. You continue to look at the benchmarks and it keeps innovating and changing. But what happens with more models? It unlocks more use cases. If you've done your evaluations and you understand what the benchmarks are for what you're trying to achieve, you can unblock more use cases you need to solve. If you think about that usage, it gives you more insights into your data, your experiences, what your customers are doing and how they interact. Then you can create your own specialized models or tune those models to your use cases. And then it gives you a proprietary signal and then you can take advantage of it when new models are released. So when we think about this change, it allows us to start shifting our strategy. We no longer think about that static hello world as pixels. We think about how we can shift this to tokens, engagement, interaction. And what's exciting to see is that I've been at AWS for over 11 years and a lot of those foundations still hold true. And when you combine it with Vercel, you get the best of both opportunities. Whether it's Next.js for how you think about your UI, but really now AI SDK for how you create your frameworks for agents. If you think about serving things in CDNs with CloudFront for your users and combining it with AI Gateway for how you serve your AI and your inference, the same thing applies to your underlying compute whether it's EC2 and Lambda or for your agent sandbox and Fluid. So these two things are ands, not ors. You need to be able to serve all different parts of your users. Again, not just your regular users, but your users are now going to be agents. So I'll dive a little bit more into these areas and try to tie it back to some important use cases and opportunities. What's become really apparent is that as people have started shifting from training to inference, there's a lot more complexity and a lot more kind of understanding and data you need. And so what's really great is we have AI Gateway where you can look at it from a cost visibility or reliability perspective. And with the partnership between Vercel and AWS, you can then use Bedrock, which allows you to pick the right kind of models for the right use cases. What I find most exciting is that you can start to pair these together. You see customers who say, you know, 'I want to do batch processing offline. I want to take advantage of certain type of models that allow me to run really long on off hours when the engineers aren't working. Oh, during the day, I have really complex problems that need to be routed to the most intelligent models. But for these other use cases that I know and I've run evaluations on, I'll use a different set of models.' This flexibility and choice is allowing people to expand what they do with AI. And then it's interesting, agents have written the code, but do you actually still trust it off the bat? You have to figure out how are you going to understand what has been generated and what it's actually trying to accomplish. So giving agents a sandbox environment, a place they can work and operate, you can understand and measure and test it, or using something like Fluid that allows you to run very, very long-running processes. What's great is you combine both of these with AWS. The logging and access to the systems that the agent is assessing using things like AgentCore to allow you to understand how the agent is essentially thinking about their context and memory. All of these pieces allow you to have more understanding on what has been non-deterministic that you now make a little bit more deterministic and understandable. And it's interesting. I can think back to the days where everyone actually had to carry a pager. If you ever worked support, you were like, 'Oh my goodness, I'm actually on call.' And you would have something in your back pocket and you're really hoping it wasn't on. Because if it was on vacation, you're going to have to leave, grab your laptop, you know, you leave the beach and you've got to open up, figure out what's going on. Those days are different today. Instead of giving you an alert, how about we ask you to just solve your problem? No more 500 errors, no more latency spikes. When those things happen, how can you remediate on the fly and have a PR land versus a page? And this is some of the advantages of Vercel's code review agent and the firewall review agent. This is what AWS is doing as well, is how we can think about security and security remediations on the fly through automated penetration testing. So you don't have to go through this cycle of picking up the phone and getting in a war room and trying to troubleshoot on the fly. And then the new frontier that I see over and over again is all about your context. In a world where enterprises are trying to differentiate, the most important thing is your business logic, your business context, your tribal insights, the things that only your company can do. And when you think about these enterprise customers, it's like you have such a legacy of systems and data that already exist, whether you're running AWS databases or S3 or OpenSearch, all available as integrations into Vercel. But then the benefit of these is that you can take advantage of these to make your agents more intelligent, more understanding of how to solve a problem with the right result the first time. And so as you think about holding these two things in your head at the same time, again, your customer is no longer the developer. It's an agent the developer is wielding. And now when you think about extending this out further, when I think about how this relates to your security, you need to figure out how you're going to do identity with Passport identity. How do I trust, give short-lived credentials to the agents that are scoped to what the developer can do? Then you can combine that with bring your own cloud, bring your own VPC. What's been great is having been at AWS, I remember when there was no VPC. It was literally just a box with an IP address. It wasn't within your walled scope and garden. But now you have essentially your own network configuration. Your ingress and your egress, your boundaries, network detection of what is leaving your system and what is not. Having that guardrail foundation allows you to then pair what you want your developers to do, how they wield those agent capabilities. But how do you do it on a really, really solid foundation? And if you dig a little bit deeper underneath the hood in VPCs with Vercel, it's where you combine two things. One, the developer experience for Vercel, the control plane, it's powered by Vercel. And then you have everything you're used to in your AWS environment. All your VPCs, your RDS, and your data stores, any private links to connect to other systems. These are all things that you're really used to and comfortable with. You have auditing with compliance controls and remediations. And now as you think about these agents that are going to be a much, much faster moving part of your ecosystem, you can still have a solid place to land them on. I think that's an incredible place to be. Speed, effectiveness, simplicity, and then powered by the things you're most familiar with. And so several of these things are actually shipping now, ship today. If you're used to using Amazon S3, which I think most of us are, it's generally available so you can use your S3 buckets, your S3 Tables and S3 Vectors. And again, what's very interesting as you think about vectors and RAG architectures. A lot of the times the efficiency gains is giving those agents the right level of context so it doesn't have to go off and do deep searching or essentially get steered the wrong way. Everything there, Launch Three products a day on Vercel are available through the AWS Marketplace. So if you're someone who already has an AWS account and you're like, 'I just want to simplify all my billing and processes,' you can launch all of these through Marketplace, connect them to your VPC, and you're off and running. Then we have partner in the Agent Plugins 1.0. We're both co-founding members here. How do we continue to help people build these agentic frameworks, systems, architectures in a way that is understandable with best practices and everything you need to build a solid foundation? So, I talked about the foundation of it, but I'd love to bring it forward because it's 2026. I just went back a few years. I went to 2023 and that felt forever ago. So, what's going to happen in 2029? You can envision a couple of kind of use cases that weren't really possible but will be possible in the future. You could be a global bank onboarding one of your end clients. Maybe it's a multinational. Maybe they have 40 different subsidiaries. They're in multiple countries and you're like, 'I've got to onboard this customer.' And how would it work in that kind of place in financial systems? There'd be a lot of meetings. 'Hey, I need you to email me this document. Oh, here's another link to go sign. After you sign it, can you PDF and scan it to me?' In a world where this would be agentic, all of that may be handled by the bank directly. 'Let me figure out which systems I need. Let me look at all of your history and records in a secure way.' You know, maybe the multinational also has a set of agents and now these agents actually start orchestrating across themselves with the right level of boundaries. 'I need to onboard you. Give me an understanding of all of your countries, your country compliance, how you do audits and anti-fraud. Give me these details back and forth.' And now what do the humans do? You still would do your compliance checks when needed. You'll still essentially be a human in the loop where these agents have conflict and they can't come to a decision. But now something that may take months, sometimes even years could be done in days and weeks. There's another world where I think about being at Amazon that we all get the opportunity to use AI on a regular basis, but in a world where instead of being a company that has an engineering team, every single person has the ability to generate and build something useful. You can imagine a Fortune 100 company, 150,000 employees. You have an operations manager in Brazil who runs your logistics and supply chain and they see latency in supply chain. 'Oh, one of the vendors is delayed on shipping.' Today, they'd probably call someone. They'd go into their system and they'd say, 'Let me see if I can find a system of record.' In the future, that operations manager who only knows their business context and only has a set of tools can say, 'I would like you to build a set of dashboards to understand my impact on revenue forecasting and all the challenges I may face in the next few days. Can you build that before lunch and give me some remediations and options?' They leave their desks, they come back, they have a running application, they resolve their problem, then they can tear it down in the moment. That is a world we can live in just in a few years, if not today. So, I know I've covered a lot of areas starting with the Big Bang, moving through what's happened with AI, and then giving some opportunities of where we work really well together. But I want to leave you with one thing. This is an opportunity and a time to think bigger. There is a moment where there's so many open-source frameworks, ecosystem processes you can take advantage of and you have a great foundation between AWS and Vercel to do so. So I cannot wait to see what you've done over the next year as this conference comes back. Thank you so much.

The SAP partnership this year has marked an important milestone for our company. In fact, this opportunity came straight from the land of Döner kebabs. If you need any recommendations, definitely follow our Döner kebab king or Vercel teammate Cramforce on X. We're really excited to welcome Sophia Leven and Phil Mistlein from SAP to discuss more than just German delicacies. You're going to hear how SAP is rebuilding its generative interfaces and services on V0, AI SDK, and JSON Render and doing it while still holding the government interface standards. So, please welcome to the stage Sophia and Phil.

Hello Vercel Ship 26. I'm Sophia Leven and I am a mom. I'm a people leader and at SAP I have the privilege of running both our design systems and our future AI and Agentic experiences. And today we're going to talk to you about a few things that we're doing. We're going to talk about SAP's design system and our brand new compositional design system. We're going to talk a little bit about how SAP is using that to build our AI and Agentic based products. And we're going to talk about how Vercel is sitting at the heart of a lot of those interactions. So, let's start a little bit with who SAP is. If you do not know, 84% of all the world's global transactions in commerce hit an SAP system. We have 440,000 customers and almost 350 million users. Essentially, we are a big company. And what we do at this big company is we produce software or interface. Um, and we do this by using SAP's web and mobile design system. And just like most design systems that folks use, that has a foundation of a design language where we have typography and colors and then built on that we have components and patterns and finally layouts and floor plans. And we don't just create a few screens internally. SAP has over a thousand products and each one of those products has hundreds if not thousands of screens. So we use this system at scale to create consistency and enterprise qualities throughout the entire ecosystem. But something interesting about SAP's design system is that if you buy SAP technology, we serve over 25 different verticals worldwide and many of our customers actually modify or extend SAP's products and they do that with the SAP design system and our technology stack. So, we completely open-source everything that we do, both the design system and our technology. And customers use that to build what we call Fiori apps, which is their customizations. And each month, over 35,000 apps are delivered from our customers and partners using SAP's design system. And that's great for what we do today. But last year, in fact, early last year, we started thinking about what the future will look like and we knew that user behavior was inherently changing. People were really thinking about things differently and you know all this, you're users of AI and systems that were going from thinking about workflow and click paths into actually natural language interactions. We're thinking about very reactive interfaces to interfaces being able to be proactive. And finally, the user is moving from being an operator of an interface and really into more of a director role where they're directing the AI or agents moving throughout the system. And so what we did is think not just about the design system we have today, but think about how we need to build design systems moving forward. How do we build a design system that's custom-made for AI and agents to use to create generative interfaces? And there's a huge opportunity here with generative UI because before with the traditional design system, all the design happened towards the beginning, right? This is traditional software development. You're talking to users. You're figuring out their problems. You're thinking about their intent. And yes, you may interview lots of customers and talk about at scale, but the bulk of the design happens at that design time. And so by the time you get to runtime, there are unaccounted for intentions that our users inherently have of a system this large. And we really can't account for those individual experiences. And so we end up designing for the lowest common denominator. But with compositional or generative UI interfaces that compose themselves on the fly at runtime, we need to work in a different way. You need to think about that same quality and design knowledge that we have institutionally as SAP but also as an industry. And how do we get that design knowledge to happen at the very end of the process when the interface is generated on the fly so that our users can meet their intent that they have, that individualized problem. And this is SAP. So we think about that in light of enterprise qualities, things like globalization. For us, we serve companies in over 90 countries, 90 different and over 90 languages. That means we support left-to-right and right-to-left text. We have a huge directive of accessibility internally, not because we want to, because it is good for the SAP business, it is a necessity for 350 million users that touch our products to find accessible interfaces. Things like security and legal compliance. All of these have been built into the traditional design system we have today and also need to be there when we think about generative interfaces. And we use the SAP design system to create consistency of those thousands of products that we have. But with generative interfaces, it's about predictability. You want to be able to type in an intent or a prompt today and tomorrow. If you type in a similar prompt or intent, get a similar type of interface. You don't want to constantly be chasing a different generative interface because the system doesn't have any predictability built into it. So we used all this and we were doing this thinking, like I said, early last year and it was great timing because SAP was also thinking about how do we create a layer on top of all these products that we have, a single layer of interaction using AI and agents that can go into all of SAP's data and capabilities and compositionally create interfaces. And so I'm going to show you next our product that does that called Joule Work. And I want you to try to spot the places where you can see compositional design in action. And you'll see that both conversationally and on the generative canvas that we have called Spaces. So let me show you that. So what you saw here is not just theory. It is what SAP is using. We are using our new compositional design system to power all the experiences within Joule Work. Both our conversational experiences, our generative canvas that we have as well as seeing things like agentic jobs running in the system are all able to be composed on the fly. And I want to deep dive for a second into what this actually means, the difference between our traditional and our compositional design system. And to do that, the best way to think about this is that a compositional design system has a series of agents and services that are able to work with other agentic frameworks, our AI core services and our harness. And what we're able to do is take advantage of that agentic interaction between the compositional design system and our base technologies. And just like a traditional design system, you still need assets. You still need assets to actually compose those compositions, but that's a new way of thinking about those assets. And we'll talk about that in detail. And you also need that design knowledge, right? That accessibility, globalization, but also how components interact with each other, when to use certain componentry, when not to use certain componentry. 20 years of institutional design knowledge and specific design knowledge for SAP. We need to work that into a framework that can be called upon agentically to compose these interfaces. But to take you into that world, I get to welcome to the stage my friend, my colleague Phil Messeldine, who is the head of our design technologies.

Thank you so much, Sophia. And it's a real pleasure to be able to unlock some of the innovations and the work that we've been doing to really try and deliver this compositional design system at scale and really generative UIs at scale across the company. So let's unpack those little blocks that Sophia was talking about, particularly around first of all the software delivery. Normally a design system doesn't have software, right? So now it's kind of a part of both and this is like a general flow which might look familiar to you if you know about GenUI kind of processes. But we have...

Intent analysis, we go to a plan, we have component selection which we're really excited about showing you some innovations there and how we're able to scale over to generation. So let's start with intent analysis. So our users give us prompts, right? So they can be very vague in terms of what's important for me to do today or they can be very specific. So they can be on the level of, well, I need to have a Q2 breakdown of my sales revenue related to, you know, X, Y and Z. So we have a very wide range of kind of query that comes in, but we need to enrich that with the context from the business and the context from the user.

So we at SAP have also had for the last decade or so been delivering declarative interfaces tied very closely to our data models. So our agent and delivering compositional design as an agent rather than a static service means that agent can also go and talk to parts of SAP, parts of the wider ecosystem to get that kind of context in from our business solutions as well as, as I say, the user context, which of course for the end experience is so vital for us. And one aspect we're really passionate about is that dual work that you saw Sophia show is delivered over every platform possible because we need to be at the point in which work is conducted by our users and from that, so we're on desktop, we're on tablets, we're on CarPlay. Imagine SAP and your, we do have CarPlay applications, but if I was going to deliver you an experience in CarPlay where you're speaking to me, it's going to be a very different experience than if I'm sat in my office with a nice big monitor on a browser solution. So all these little hints come to us to give us the intention analysis that we need.

Then we move to planning, of course. It's all very well. This is what the user needs. This is what the work they need to conduct. Now how do we plan actually an interface, an experience for that user? And you know that doesn't just mean putting an input field here or a button here. It's really deconstructing that intent, the data coming in to say, okay, the user needs to make two decisions. They need to see these kind of data points and we attach signals to these kind of data points to say, is it complex data? Is it a series of data? What kind of decision is it? A binary decision? Is it something where they need further support? So we build a plan, really a structure of what's needed for the interface without yet going into the detail of individual components and things like that.

And once we've got that plan, our agent then coordinates with our catalog service, and this is the part where I will deep dive into, which provides us scale. So as you know, we have primitives, and anyone who's been building in the GenUI space, you know, a primitive is this leaf on the kind of render tree, which is the part that you send to AI to say, go make me an interface with these bits and pieces. We need to make that as small as possible because, as Sophia said, we at SAP have over a thousand applications with thousands of screens. You can imagine there's a lot of opinion within those product owners of how their data should appear in these generative experiences. So we need to scale that, and we've got some really good work there to show you how we're doing that with the cell at the heart of that as well.

And then of course we receive that spec from the catalog, but attached with it is the design knowledge of how to use those components and those compositions in the right way. Right back to that original intent analysis. So then we can render that on the screen.

So let me deep dive a little bit into the component catalog. As I said, we got primitives. They're blocks of code that we ship in the clients, right? So for us, anytime we need to ship a new primitive, we need to update the clients, and as you saw, we're from mobile to web everywhere. So we will need to keep that nice and tight so that we can scale then solutions on the top. So what we provided is actually this idea of a composite specification. This is a pre-curated specification of use of those primitives, which then is basically a subsection of the JSON render tree, right? So it's just saying this is a nice construction of these composites, and what that allows us to do is kind of really layer the way in our information architecture of our interface.

So we have what we call atomic primitives, text boxes, containers, the smallest element possible which can be constructed, but they can't be used alone, right? We don't want to just have an interface with a box in it, right? Then we have control primitives. These are icons, input fields, they've got a bit more depth to them and also tie to the target technologies to have that kind of primitive. Now in our early experiments, we're able to shrink that layer and still build the same level of interface flexibility with around nine primitives. This means we will ship, say, a very small set of actual primitives within our clients, giving us maximum flexibility to build compositions, which is literally data. We can store those in databases as we do in the catalog service.

And recently, even with the introduction of these new classifier models like Jev, we are able to actually make that choice even easier of which components, which composites fit for this right service. And as I said, we have these signals. These signals are attached to the composites. So we can match and say, hey, if it's a time series, I'm going to use a composition which is a line chart, but rather than it being a block of code on the client, it's constructed from primitives. So we can have maximum flexibility in analytics too.

And as Sophia said, what's super critical for us is moving that knowledge of designers, not replacing designers, but moving that knowledge into this catalog as well. So we have usage rules of those composites. When should it be used? How should it be used and in what form? And universal rules: every interface from SAP has to be accessible. It has to fulfill certain product standards. And those are then crosscutting any kind of composition. Then we can take a slice of this catalog to say, okay, these are the four or five composites which would fulfill the user's original intent. Now we can scale, now we can have multiple contributions and use AI itself to select what kind of compositions are needed, and then of course we get the end rendering with a dynamic skill that takes the design knowledge of what's been selected from the catalog that brings us brilliant scale.

Now I'm going to show you a quick demo. Hopefully we have time. Where we're using Eve alongside this. So here I've got a primitive catalog. I've got a bunch of components in here. Sorry for the bright light. We'll fix that soon. And these primitives basically are, you know, inputs, avatars, buttons, and things like this. Just a representative set. And then we have a set of composites in our catalog. These are predefined patterns of how those primitives should be used together.

And now I go to my lovely Eve interface, which we love because we can rapidly prototype, and I've cooked this up with some SAP systems. So here I'm asking to show the profile of a mirror, and this is actually a way in which we're visualizing how the agent harness is working. Anyone who knows Severance might get some hints there. And basically, you know, the harness calls our HR service, and then we tell the harness, anytime you need an interface, come to us, deliver that data, and we can push that forward and deliver you an interface. Now that interface comes back, but it's quite generic. It's looking at the general patterns that are available, but it will deliver you an interface.

Now let's say our HR solution, SuccessFactors, comes and says, look, we've got a brilliant way of showing people across all these generative experiences, but they don't want to have to ship new componentry, have it integrated. Instead, they just add the record to the database. Essentially, now without any change to the client, our agent is able to go through the same process here, picking up the HR data again, and now when the composition additional design agent is being triggered, it's now available in the dynamic catalog to pull out that composition for a people profile.

And even better, because it's an agent, it can go back to the harness and say, "Hey, it would be great. This composition tells me to get the people pictures of the people. You didn't send me that content originally." So it can go back to the harness, say, "Can you provide me that context?" And it does. And now we get a much better composition, consistent, predictable, but still flexible. It's just a spec. So AI can deliver it too.

That was using Shaden. Here we're using in dual work that same composition. The renderer just here is our native React componentry. And that means we can also scale that to complete dashboards of content, all using these compositions at the heart. And because it's VCL, I put a dark mode in there too, so that we can tone down the lights.

Okay, I'll be very quick. Vercel is also helping us and our customers deliver generative experiences. Vercel's v0 is now the de facto standard vibe coding environment inside SAP. We're using that to conceptualize, to predict, to move traditional and compositional experiences. And it will soon be available as planned for our customers themselves to build experiences within JAW Studio. And we're using as official skills all coming from SAP use skills.sh solves huge business problems for us. This lovely little tool that means that we don't have to do support for all of our customers of how to install within their coding agents and so on our skills. It's just there, one line. Perfect.

And we're not just faking this. Just on Monday, I was in San Ramona, our institute. Over 80 of our top designers are learning compositional design, exploring it with v0 at its heart to see how to work, and the learnings we're getting from just rapidly being able to use this tooling is fantastic. Now, Sophia, maybe we highlight some of the things we've seen today.

Yes. So, what you saw today is how SAP's AI experiences are evolving with Vercel at the heart of a lot of those. You learned how v0 is our go-to prototyping and vibe coding tool for both the traditional and the compositional design system. And hopefully you learned a little bit not about compositional or generative design systems, but how we were doing that at scale and enterprise quality at SAP. So thank you so much for your time today.

Thanks so much, SAP team. Last week, we hosted a dinner on the future of benchmarks and eval partnership with none other than Benchmark, the firm. G sat down with 12 emergent founders who are building at the forefront of how this critical space is shaping where models run in production and, of course, have efficacy for the core tasks we expect of them. Merore generates the human data that trains and evaluates frontier AI models. Behind the scenes, hundreds of non-engineers build their own tools on open-weight and closed models. Built on Vercel, Merkur avoided the chaos with managed identity layer that every app inherits, full visibility into spend, and foundation that scales to the next agents that they're building. Join Aaron, head of security, and Arty, VP of engineering, to hear how.

Hello. Hello. Hi everybody. We're here today to talk to you about how through Vercel we've been able to enable hundreds of builders across the business to ship with confidence and how we kept control and maintainability without becoming the gate. Everyone is a builder.

First, let's talk about who Merore is and what we do. We connect domain experts, think doctors, lawyers, engineers, writers, with frontier labs to provide data that continues to push the frontier. If any of you have interacted with frontier labs and their research teams in a meaningful way, you'll know that they're running and sprinting constantly with speed and velocity with almost no rival.

Our growth and business teams had consistent pressure on product and engineering. Things were not scaling. We could not keep up. Growth teams then began shipping their own solutions. Great, problem solved. Scale has been reached. However, the exposure surface has increased. How do we solve this with a paved path and enablement without putting up and blocking with a security gate?

Okay, today we have 2,000 projects. Last year we had less than a dozen. Most of these projects are owned by teams outside of the engineering organization. Each ships with the same three questions: Who can access and how? What are its capabilities? And what is shipping underneath? Requiring a security review on each is a bottleneck that we did not and could not introduce. It would also introduce workaround for teams where they would find ways around it anyways, thereby reintroducing the same problem. Instead, we lean on the default on the platform.

The first thing that comes up with any application that you're shipping out is identity. How do we provide identity as a default? Before Passport, each application owner had to decide what identity layers they were building. Are they going to build it with Vercel authentication using a password, homegrown auth with a library, or public with the hopes of security through obscurity? Enter Passport. This replaces those decisions with one. We put IDP in front. Same login, same passkey, zero friction. The builders write no auth. It's inherited by the platform. We are the first Passport customer running in days connected across hundreds of projects. That covers employees, our own Merore workforce, more straightforward, more stable.

Experts outside the company, though, the hundreds of thousands of them, they have to gain access to these services as well. This is where configuration comes in, utilizing what my identity team built, our audiences tool using Vercel Passport as a first-party primitive where we can pick a collection of experts, 10, 30,000, it doesn't matter. It connects to Vercel connection, connects to Vercel Passport, and now they're provisioned in seconds.

Once the engagement ends, that group is removed from our IDP. Access is removed. This gives us offboarding by default, and it's a much cleaner experience. Security is happier. Engineering is happier. Growth teams are happier. Applications shipped now have one identity layer with scoped access and clean offboarding. That is who can reach our application. Now I'll hand it to Arty for an even larger surface, our inference.

Thank you, Aaron. One of those tools that our experts use is not like the other. We have around 100,000 experts in our platform, and they use LLMs in every part of their core workflows. They use LLMs to guide them through the projects they're on and answer questions. LLM is a key portion of our quality control story where it helps us to create better data. And finally, we use it to create invariance of a human data to increase the data variety.

Naturally, our teams run a variety of models, some open, some closed. And as projects come in, it's paramount we're able to switch one model to the other on a moment's notice. So what that meant before AI Gateway is that whenever a new model comes out or a new project comes out, you would have to rush to a specific inference provider and say, can you please give us more capacity? Sometimes we'd have to sign a new contract and basically ask for a new rate limit. Now that we switched to AI Gateway, we have one endpoint for both open and closed source models.

After switching to a gateway, in the first 10 days, we were able to serve 80 million requests, roughly 63 billion tokens. Our grading speed dropped from 12 hours for a batch grading run to evaluate an LLM to 2 hours. Probably the most interesting example here happened last week. On Friday, we decided to switch a portion of our inference to GLM53. Instead of going through very tedious procurement process where we go to a bunch of providers, we work directly with our sales team. By Tuesday, we had 300 million tokens per minute allocated to us without any extra back and forth procurement doing MSA reviews. Our procurement team is happy. Legal is happy. Aaron and I can go deliver that business value.

Now that we've got access to the inference capacity, the next question is control. We have guardrails on every single key. So what it means is that every single API key gets a spend cap, gets an expiry, gets an owner. Going back to the 100,000 experts we have, it's paramount. That's true because projects take a different amount of time and need different types of permissions. Zero data retention is enabled by default for all providers, critical for a sensitive industry like ours. And finally, we don't give out raw provider keys. We just give out Vercel keys that people can call directly.

Now that we talked about the capacity portion and we talked about the control portion, let's talk about the finance's favorite question, which is who is spending what amount of money on what. AI Gateway is providing us one view of every token that flows through the system, which means that we are able to say who is the user spending this amount of dollars on which project and which workload. We can enforce budgets. One project can spend a million dollars, the other one can spend 10,000. We can also see request-level attribution and plug it into our own telemetry stack. And finally, the best part, there is one bill as opposed to a dozen.

We covered the human scale and consumption, but there is another actor that is unlike humans that is entering the picture. We all talk about gateway for agents. We've heard it all day, and it's something that we talk about a lot at Merore as well. Of course, my security team and identity teams are building agents. So are our fraud teams. We have a mono agent at Merore. Everybody is building agents. And this is where every security person starts to think, oh no, right? How are we thinking about identity? How are we thinking about access?

When we think about agents, I immediately think of them as a very capable intern. They're provided a goal. They're going to strive for it and go after it in any way possible to achieve it. Where agents differ a bit, of course, is that they don't tire, they don't sleep, they don't ask, they just go. They're going to do things that we may not have even intended for them to do when we ask that question, like escaping a sandbox.

So now we have to think about what is the identity we assign to it. What is the job that we scope it to? What other permissions are attached to it as well? If it is inheriting my user permissions, then we've already lost. If it's sitting in a public channel in Slack, for instance, and consuming the same context that I can consume and sharing out that content broadly, imagine if your CFO has this same capability, right? And it starts sharing financial documents or your people team. These are things we have to make sure we're scoping down across our workspaces, across our different surfaces that our agents have access to. If we're running grading jobs, those permissions have to align to those grading jobs.

It also gets its own gateway key. As we continue to spin up more and more agents, we have to ensure that what they are accessing is also aligned to what the key should access as well. The model that it should have access to. We safe list those to ensure that the only models that it should make use of are the ones that it is able to invoke. It has expiry associated to it as well, and of course a spend cap so that way we don't have any runaway.

We've talked about a couple different patterns here, and we can talk about what is next as well. But the primary thing that we have to key in on is making the secure path the fastest path and the easiest path for all of our builders across the business. Our path one here was Passport, signing in by default, making it easy, putting the control on the platform side, removing the onus of authentication and other critical paths from those who are going to ship out a couple hundred apps a week maybe that are sitting across many disparate surfaces and teams.

We have to think about the 2,000 projects, billions of tokens. The amount of security reviews this would take is untenable. We can't have a security team scaling in par alongside the business. We have to solve it with agents themselves while also thinking about how are we securing them.

We're going to continue as a business and as an industry to rely more on the open models behind the agents. Our team internally will also be leaning on the secure defaults that Vercel provides to us as a platform, which is going to be organizations. So that way we're not spinning up new hand-rolled teams while also at the same time trying to toggle the same settings across them. It wouldn't be tenable.

We have to think about it from a managed user standpoint as well. So that way you're not all of a sudden surprised by something landing on the public internet from your organization and a user within it. All of these things allow us to grow and continue to move as a business and scale alongside needs. But what it also does is it ensures that we get out of the builder's way. Thank you very much. We're hiring.

Maybe I saw a few of you last December in the ClickHouse line trying to get to the re:Invent Chainsmokers party. And you might be excited to be back there again with us in a few weeks slash months. Today we're excited to have the ClickHouse CEO and founder joining us. You might know ClickHouse as someone who is a part of the open-source community since 2016 as a database for web analytics in which thousands of companies were already building and running in production before there was even a company. Sound familiar? Today it spans real-time analytics, observability, AI engineering, and managed Postgres. We'd like to welcome to the stage, like I said, Yuri, to share why the next decade of data infrastructure gets built the same way. Welcome, Yuri.

All right, good afternoon everyone. Another crowd. So, my name is Yuri Zilleski. I am a co-founder at ClickHouse. Just to kick off, by show of hands, how many of you guys have heard of ClickHouse before? Oh, almost everyone. How many of you have used ClickHouse open source? Okay, a few. But what about ClickHouse Cloud? Okay, so most people have heard of ClickHouse but haven't used it yet. So you're missing out, but it's not too late. You know where to find it. And if you haven't heard of us, ClickHouse is the fastest, most scalable, and cost-efficient analytic database that allows you to process petabytes of data in milliseconds.

And it was first developed by my co-founder Alexey Milovidov back in 2009, and then it was open-sourced in 2016. And it was quickly adopted by a number of big technology companies like Cloudflare, Uber, Lyft, Bloomberg, Cisco, China Telecom, Deutsche Bank, eBay, Spotify, lots of companies. And then in '21 we founded the company to continue to govern the open-source project and to develop a commercial product around it. But by then we already developed this amazing open-source community and the technology was battle-hardened.

One of the things that really helped us build this amazing community was the pace of innovation. Most database projects, it usually takes, you know, once a year releases, maybe every 18 months. ClickHouse puts out a new release of its open source every single month. Since it was open-sourced in 2016, there's been more than 120 releases, and each one has lots of new great stuff in there.

And so by the time that we started our company in '21, there were already over a thousand contributors that pushed over 20,000 pull requests into the codebase. And of course by now, five years later, we have nearly 3,000 contributors and around 100,000 pull requests in the system.

So, and ClickHouse is not just a fast database, it's also a fast-moving company. When we launched, when we started the company, we launched our first version of ClickHouse Cloud in less than a year. And of course, whenever you're building a commercial product on top of open source, you always have this fear: if you have great open source, why would anyone pay for your cloud product? And of course, you can build a fully managed product. You know, you can have enterprise features, security, compliance, nice UI, but at the end of the day, it comes down to the bottom line. You know, people want to save on costs. So how can you create a commercial product, a paid product that's cheaper than the free open source? Well, it turns out that you can if you architect it right.

With ClickHouse, the way that you deploy open source, it's shared-nothing architecture where data sits directly on the compute nodes, typically on expensive SSD drives, and also because there's so much data to move around, you can't really resize the cluster, so you overprovision for your peak load and then you just pay for it 24/7. When we moved to the cloud, we separated compute and storage, and the data persists in cheap and very durable object storage like S3, and the compute is totally stateless. So you can autoscale and you only pay for what you use.

So as a result, you're not just getting a better fully managed product, but it's also cheaper than what you had in open source. So migration is a no-brainer. And of course, to build a successful commercial product, you really need to meet your customers where they are. That means having flexible deployment models. So we have fully managed cloud. We have bring your own cloud where we deploy the data plane in the customer account. And we also have the private deployment option in any environment, even air-gapped environments. And it's also very important to have broad geographic distribution.

So more than 50% of our revenue comes from outside of the US. So we deploy on all three major clouds in 38 cloud regions all over the world. So whether you need to optimize for local residency rules or you need low-latency interactive service, there's always a region that you can find near where you are.

There's this misconception that the open-source and the commercial side of your business are in tension with each other, and you have to artificially starve. You have to limit the functionality in the open source in order for customers to be enticed to move to your commercial product. From our experience, the opposite is true. Having a fully full-featured, robust open source is the best sales and marketing channel for your commercial product. And also, the biggest fear that any enterprise buyer has is vendor lock-in.

So if you have an open-source version of your product that is functionally equivalent, you know, the same queries that you can run in the cloud you can run on open source, it's the best insurance policy that if something goes wrong, they can always fall back, even though in reality people never do that. So what we found is that having fully featured, robust open source drives a lot of demand for your cloud products, and that generates the revenue to continue funding open-source development. So you have this flywheel that leads to happy open-source and satisfied commercial customers.

So Vercel started as an open-source project, Next.js, and over the years it evolved into a developer platform. So ClickHouse also started with a single open-source project, but over the years we've added a lot of functionality. There are five main use cases. You know, there's the real-time analytics, observability, data warehousing. Now we have transactional processing with our managed Postgres, and of course the fastest-growing use case, AI engineering. We've also made seven different acquisitions. Each one of them has their own open-source community.

Of course, at the very beginning when we were just starting out, the main focus was on taking this amazing database engine and creating a cloud product out of it. And of course, it takes a lot more than just taking your database binary and plopping it in AWS. The ClickHouse Cloud product has hundreds of different components and services. You know, you integrate with data sources, security, data visualization tools. There's ClickPipes, managed ingest pipelines for data pipelines and also for CDC from transactional databases. You know, you integrate with different data formats, data lakes, catalogs. There's a lot of stuff out there, but fundamentally at the end of the day, it is still a single product.

Well, fast forward to today. In addition to ClickHouse Cloud, we also have managed Postgres. Just like ClickHouse, it is the fastest Postgres out there using NVMe. We acquired HyperDX, Lenfuse, and launched ClickStack, so rounded out the observability offering. We have our data warehousing offering, and with the acquisition of LibChat for conversational analytics, managed MCP. Now we also have our agentic stack. So now ClickHouse is a collection of different data management products.

Well, where are we heading? What's the future for us? So the ultimate goal is for ClickHouse to be a universal data platform that serves all of your data management needs. And of course that includes first-party products that we talked about, and we're launching more. We're working hard to partner with great vendors like Vercel on deep partnerships, and of course we'll be developing our solutions marketplace so hundreds of different third parties can plug in their data solutions into our ecosystem.

I mean, that all sounds great, but you know, when I look at our experience of integrating acquisitions and partnerships in the past, it would take many months of really hard engineering custom work to make that integration successful. And if we hope to have hundreds or thousands of products, it's not going to work. So we need to have a platform, and we developed a platform that makes these kinds of integrations much more efficient.

So what does it take? I mean, it all starts with security. Our customers are trusting us with the most valuable thing that their enterprise has, with their data. So having security, data privacy, and governance is the absolute top priority. And what that means, you know, we need to have managed unified identity with single sign-on, network security with features like private connectivity. We need to have consistent and secure ways to manage encryption keys and other secrets, and of course data governance and compliance, you know, from residency rules to regulatory certifications in every jurisdiction where we operate.

Data plane. ClickHouse manages exabytes of data for thousands of customers. So as you can imagine, we're deploying huge fleets of compute and storage to make it happen. So it's very important to do it effectively and efficiently. So we standardize our compute and orchestrate it on Kubernetes, and we've done a lot of work to hide away all of the configuration complexity.

We need to provide consistent developer experience, including pre-production environments like local dev and staging. Having an accurate service catalog, you know, discovery is a problem, especially if you have hundreds or thousands of services and dependencies. Where do you find them? How do you connect to them? What are the APIs? What are the SLAs? How does SSO work? So having all of that well managed and consistent and documented is really important. And of course, to ensure high reliability, you want to provide complete observability platforms: logs, metrics, traces, dashboards. And you also have to make sure that you're managing this huge infrastructure efficiently. So you need cost management tools and best practices there.

And you also need to platformize the control plane. You know, it's great if you have hundreds of products and services, but if it all feels like a kitchen sink of unrelated stuff, nobody cares, right? You need to have consistent user experience and seamless flows that go across all of those different products. Similar look and feel. So control plane needs to operate like a platform with a library of UIs and API templates and design templates and reusable components so it all fits together nicely. And of course, these days it's not just about humans. Agents need to be first-class citizens. So everything that you do in the UI, there needs to be complete parity in APIs and command-line interfaces.

So ClickHouse was open-sourced in 2016, and it was only six and a half years later that we launched our first commercial product. Vercel, they followed the same journey. So focusing on the adoption and building a vibrant open-source community paves the way for commercial success years later. But in order to provide even more value to your users and your customers, you really need to turn it into a platform.

A single agent run produces application data, traces, evals, logs. But nobody wants four systems to query to get an answer to one question. So with this proliferation of agent workloads, these data silos are collapsing, and open-source technology and open formats are making that possible. And of course, these days agents are not just used to query the database. Oftentimes companies are relying on LLMs to decide which technology to use in the first place. And open-source technologies with public code and documentation and years of forum answers and issues, they all feed into the training set for these models. Whereas proprietary systems are much less, much more invisible, right? So it's not a secret that Anthropic, OpenAI, and most other AI labs, they're all using ClickHouse under the hood. And apparently a big factor in them deciding to do so was their own models recommending it.

Langfuse is a popular open-source-based AI engineering platform. It provides tracing, eval, and observability for AI applications and agents. And Langfuse integrates natively with the Vercel AI SDK. Langfuse is built on ClickHouse, and they actually joined our company earlier this year. Users instrument agents using Langfuse and run eval, and then they deploy them in production on Vercel. So this has been a great partnership, and today I'm very excited to announce that later this year ClickHouse will actually launch on Vercel Marketplace.

So, one-click provisioning from Vercel. You get a 30-day free trial with $300 worth of free credits. Payments and invoicing will all be handled by Vercel. And you get access to the full set of capabilities of ClickHouse Cloud, including ClickPipes, managed Postgres, observability, ClickHouse agents, and everything else that we provide. So, we're really happy to partner with Vercel and bring the two of our communities together. Exciting stuff.

So, it's interesting. I was actually looking at the agenda for today's conference between my talk and the happy hour, and you'll be hearing from the CEOs of four different companies: Cerebras, Typesafe AI, Shopify, and Vercel, of course, right? It's interesting that all four of those companies, they're all running on ClickHouse under the hood, but they're all providing very, very different, running different businesses, right? From AI inference chips to developer platforms.

But it's funny, like, out of the four, three of them are using ClickHouse Cloud, one of them is using ClickHouse open source, but we love all of our users of ClickHouse. But even though their businesses are very different, all four of them are facing the same challenges in terms of scale, performance, reliability, and security while operating on huge volumes of data. The same challenges that we face at ClickHouse and all of you are facing within your own company. So I hope we can all come together as a community, learn from each other, and together we'll solve all of these hard problems. Thank you.

All right. If you haven't lived under a rock for these last two weeks, you've heard of or started playing with a little model called Jev. Diego Almeida co-invented InstructGPT and RLHF and worked on ChatGPT and GPT-4 at OpenAI and Google Brain before starting Typesafe AI, a company building system one models aimed at a true no-human-in-the-loop automation. Many of you might have first leveraged Jev through our very own AI gateway. The founder today is joined in conversation with the Cerebras CEO Andrew Feldman. Feldman had a big year with Cerebras' IPO in May, debuting as one of the biggest IPOs in US history since 2019. A wafer-scale chip maker and designer is the perfect partner for this dialogue on rethinking basic LLM assumptions around reliability, latency, and cost. The ultimate question for the builders in the room is: what does it take to embed AI deep inside real systems instead of just bolting it on? They're joined today by our CTO Malte Ubl in this fireside chat. Let's welcome them all to stage.

Hey everyone. I'm back. We're following the F1 theme today with the panel about fast AI. We got folks from two companies here who approach us from a very different angle. Why don't we start with quick introductions? Andrew.

Heck yeah. I'm known as the Jev guy. Co-author of RLHF, ChatGPT, and now Jev. I'm super passionate about making AI actually useful for software, and you, I assume you all know that it's way faster, way cheaper, and in many dimensions way more reliable, too.

Wonderful. Yeah, we're all super big Jev fans here. Also a fast entrance, like this is such a good place to be. I think you could see a future where programs get fully created on the fly. Maybe starting with you, do you still need an interface in that world where the program just comes to you, and what might it be?

Could you say the question again?

Oh, like if a program is being created as you type, basically, right? Is there still a need for like UI interfaces, etc.?

I actually think this is a better question for Andy. I'll say my answer to this is that I really obsess on reliability. I think that software, the creation of software, does not meet my bar of fully autonomous reliability. And I think that AI should be in the inner loop of software. And if that can actually make software itself, that is super awesome. And also, if I'm realistic about where AI is right now, we have not automated significantly easier tasks than software, which I think is tragic. And I want to focus the brain power of these incredible cognitive cores on automating that stuff. I hear people are doing really slick stuff on generative UI. I think that's super duper cool. And also, we are going to be laser-focused on the basic work until that stuff is fully solved, and then go and add nines from there.

All right. Still a little bit too far in the future. Do you have a take, Andrew?

Cool. Andrew, I saw a Mistral demo earlier this year. Maybe you can tell us a little bit about that and what you've seen in that space from other partners as well.

I think, I mean, I was there very early when Vercel started building v0, which was able to make web pages, and it took forever, right? But I think there's this pattern generally in AI where you try something out and you can feel that it would be good if it was fast.

Yeah, I think we're relearning many things that we knew about software. You know, there's 50 milliseconds perceivable instant, 200 milliseconds keep the attention, everything beyond, you're in a very different modality. Diego, maybe over to you. You've given us a sub-millisecond model. Like, what's the coolest thing you've seen people build with it?

Oh boy. I'll give the disclaimer that I'm again all about reliability, so I don't know when demos are real or not, but I will tell you the one that I want to make happen, and I will have our team work on to make sure it works. To me, the coolest thing was I use WhisperFlow sometimes in a quiet corner. I don't use it around my coworkers. I'm not a terrorist. And the problem with WhisperFlow is it's great for entering text, but sometimes you actually want to command the computer, and it actually takes intelligence to switch kind of like Vim's modes. And someone made a demo where they were basically reading the text going in and figuring out like, is this a command to change the application or is it inserting text? Are you supposed to click somewhere? And I was like, holy crap, that's the missing thing to get rid of keyboards entirely. That is so unbelievably cool because if you had an intern that you were talking to with instructions, of course you could do...

that, right? And I just didn't even realize it was an issue until some—I hate—I don't know who made it. Some random person on Twitter made it. Like, oh my lord, that could be the future of interfaces.

By the way, I will like—I need to fangle for a second. Like Jeff has given us a feeling that I think hasn't been around for a while where like the world of possibility is bigger.

There's all this stuff you can suddenly do where like previously you had to have like some ML team work on it for 3 months only to figure out it doesn't work. Now you figure out after 30 seconds that it doesn't work or you figure out it works, right? Which is which is...

And it also goes to Andy's point about like the millisecond boundaries for feeling near instantaneous. I don't think that—I haven't talked to him about this but I assume we're on the same page—I don't think there's a lower limit to how fast we should make it.

Exactly. You could just like do more intelligence in the same loop and still feel feel instantaneous. It would be so cool.

Yeah. Sometimes you'll hear people say, 'Well, it's okay if my agents run overnight.' Like, well it would be better if they ran before dinner and you know your agents were doing way more work than your competitor's agents, right? I mean there is no lower lower bound to how fast you want thoughtful and useful work done.

One thing—so I shared actually earlier today that we're serving about two trillion requests a month. Like I would love to live in a world where I can run an AI on every request. Are we there?

Which means they are examining and scrubbing all the traffic that's leaving your site.

Yeah. Fascinating.