Jean
We now still have one person running that in the US, and then about 20% of a person doing all of Europe and all of APAC. And when this came out, people decried the end of the knowledge worker. But for us, really what we started— what we did was to shift all of those people into more valuable roles. So I'll give you a little sense of what we did with the lead agent. What the working model that we've used for all of our internal agent development is basically a tripod. It's a GTM engineer, a data scientist, and then the best person, the best subject matter expert in that function. And they sit down shoulder to shoulder and document the best practice for that particular function and then encode that in workflows that ultimately form an agent. We then keep a human in the loop so that human will basically QA the agent. The agent won't be allowed to autonomously execute its action. And then over time, as the subject matter expert has less feedback for the agent, we finally pull that person. Last year was declared the year of agents, and I think reasonably speaking, we didn't quite get all the way there on that one. But I think we're now with the infrastructure available in 2026, able to finally get there. So 2025 really ended up being much more about assistance. It was great for copilots, personal productivity, good prototyping, things that looked sexy and new, but very little in the way of actual agentic capability at scale. Now we're getting to the point where you can have agents that actually act, that can complete end-to-end complicated business outcomes. And we're moving towards a world where agents can work as sub-agents underneath a super agent to ultimately collaborate and complete that much more complicated actions. What happens though is most of us have not started doing anything at scale. And so you haven't hit all the rough edges when all of a sudden that agent is operating at 100 or 1,000x the scale it was previously. When that happens, you start to have infrastructure problems, costs in place you didn't anticipate them. And it's because the cloud infrastructure that we've all grown up on for the last 20 years wasn't built for this era. It's built for a simpler world where you have a request and you go out and return an output. But that's not how agents function. Agents are much more complicated. They're thinking. Talking to an LLM, with long-duration execution and tool calling, and all those things actually require different infrastructure to execute them effectively. So Vercel, along the way, has built a bunch of new agentic primitives. We call this agentic infrastructure. On top of that, you want your infrastructure to do fundamentally different things. The first thing you want is an effective deployment target for agentic and engineering. For Vercel, 1 out of 3 deployments from our customers was now generated from an agentic engineering offering like Claude Code or Codex. So we've optimized the infrastructure to come from where code is being written today. 2 is the primitives I just discussed. They're different in an AI world, even if things like compute or sandbox have been around for a while. And last but not least, you want infrastructure that is itself agentic, that gives you solutions rather than alerts, dashboards, and problems. So what are the 3 things to take away as you all think about building agents, both within your own products, but also what we call business agents, the internal ones that you will end up building to make your own teams more successful with their bespoke workflows. First, agents need headless, composable architecture. Agents don't live in UIs. They call APIs, they hit MCP servers. If your product isn't composable and developer accessible, you're invisible to agentic workflows, and you're simply not going to be in the stack. Second, agents require you to invest in your data foundation. You should obviously be using data to decide how to cut territories, set quotas, and run your business. A strong data foundation has always been critical to the success of your business, but now data is the fuel that powers your agents. Good data equals good agents. So if your semantic layer includes highly accurate customer enrichment, your lead agent qualifies better than any MQL framework could have, and your copy sounds more natural than any SDR could have ever written. And 3, agents change the build-buy calculus. Teams no longer need to default to buying just because development is too costly or slow. So I'll show you how each of these showed up for us. Let's start with Deal One. This is our meeting intelligence agent. Deal One ingests every call, generates notes with action items, and posts coaching suggestions directly to internal Slack channels. It proposes CRM field updates. It tracks competitive mentions and objections over time, and it runs postmortems on every closed lost deal. And all of this happens where we already work. For us at Vercel, that's generally in Slack. When a rep goes into a channel and mentions @deal1 with a question, the agent does a Slack real-time search, queries D0, another agent of ours, for data as a sub-agent, pulls Gong transcripts, searches our internal knowledge base, and streams the answers back into the Slack channel. The rep never leaves Slack, and the agent never has a UI. For Deal One to work, Gong needed an accessible API. Salesforce needed webhooks we could actually compose into automated workflows. Because those external products had developer surfaces, everything worked. If they didn't, we would have gotten rid of the tool. Next, there's the playbook platform. We kept seeing a pattern in our best reps. They knew to reach out when a customer's usage spiked or when a high-value prospect ended up on our pricing page. They did this instinctively, but it didn't scale. It depended on which rep owned the account and whether they followed through on their signals in their dashboard. The Playbook platform automates all of that. A signal fires like a usage spike or a high-intent pricing page visit, and the platform matches it to a play, generates personalized outreach, and surfaces it to the rep for a single-click review. The best reps' plays available to everyone are automatically triggered. The before, we should reach out when usage spiked, but it never happened consistently. The after, an 11 out of 10 experience on every account, every time. Notice no separate UI to log into. Signals flow in, drafted outreach flows out, reps review in their existing workflow. We built it all headless by design. The companies that win in the agentic era will be the ones whose products have headless, composable architecture. You've seen this signal coming from the best enterprise SaaS companies out there. Box, Notion, Salesforce, they're all making major bets on their developer platforms right now. So the to-do here is simple, even if the work isn't, go build the developer surface areas now. MCP servers, webhooks, APIs. Next, data. Probably the most popular agent at Vercel used by the entire company is D0. D0 is a data analyst agent that everyone at Vercel can access via Slack. Questions that used to take a week to ticket and get an answer back to from the data science team can now be answered in less than a minute. It'll answer things like, what was our token volume through AI Gateway last week? What companies do we have logo rights for in the UK? Who are our highest revenue startups— startup customers using Sandboxes? d0 powerfully democratizes data across the company. To do this, d0 translates natural language questions into SQL queries against our analytics infrastructure, letting anyone on the team answer questions without writing code or waiting for the data team. To power DZero, we invested heavily in what we call the knowledge base. It's a structured, queryable representation of our business that all our agents can reason over. Our head of data science built a semantic layer on top of model to use our— on top of a model of our revenue, breaking down the business into the smallest causal units enriched with third-party and first-party signals. That layer is what powers DZero. It's what makes Steel One's analysis actionable rather than just interesting. And it's what makes the Playbook platform contact the right companies with the right message. Every agent runs on top of it. Without it, agents hallucinate or give generic answers. With it, agents are grounded in our data. Finally, agents change the build-buy calculus. With the rise of SaaS, enterprise software was a procurement exercise, but now robust applications and agents can be built and run at scale in a matter of weeks. Companies are building for their own unique workflows. To give you some perspective, the lead qualification agent that I opened with Costs us under $5,000 a year between infrastructure and tokens to run. It takes about 20% of one engineer to maintain it. That's a 32x ROI. We used to have 10 people and their salaries. It's now $5,000, and it operates 24/7 with faster speed to lead and all the quality of human Equivalent metrics. That said, building isn't automatically the answer. So every quarter I ask the same question of my GTM engineering team. Has another company out there built something better, faster, or cheaper? And if the answer is yes, our agent's gonna go. So how did we actually do all of this? We had a GTM engineer, as I mentioned, shadow one of our best SDRs for a few days, shoulder to shoulder, looking at their screen together. Watching every single tab she opened, LinkedIn, Built With, the company website, CRM, Slack history. The engineer converted each of those data sources into a step in a tool calling workflow. We documented it, made the workflow leverageable before touching any AI. After building our first version, the agent ran in production in shadow mode for 6 weeks. Our best SDR reviewed every single output to create a feedback flywheel. And then finally, she couldn't improve it anymore. The architecture reflects exactly what she was doing manually, but now it performs like the 90th percentile rep 100% of the time. We applied the same framework to 30 different SDR workflows from event follow-up to PQA flows, to specific time-based campaigns. SDR quotas increased by 30% this quarter. And again, the lead agent was not hard to build. A single engineer prototyped this over the weekend, and it was in production 6 weeks later. Then there's Vertex. This is our customer service agent, like our internal Sierra. That powers vercel.com/help. Vertex costs us $300 a month in infrastructure, plus $12,000 in tokens. So $150K a year. It operates at significant scale, handling thousands of technical cases a week, and 3 engineers work on it. 3. We started with an off-the-shelf solution, But weren't seeing enough results. We built something in-house in 2 months and had it in production. Compare that with some of the agentic support companies out there with 150 engineers running the equivalent workflows at dramatically higher costs. The difference isn't magic. It's that we used infrastructure built for agents from the start, rather than discovering the cost problem after we'd already committed to an architecture. All of our agents, Lead Agent, the Playbook Platform, Deal One, Deal Zero, run on Fluid Compute. The infrastructure that powers our internal agents is the same infrastructure that our customers deploy their own agents and applications to. Most rules of cloud infrastructure are broken by agents. Fluid runs high-performance mini servers, and compute only triggers when needed. Plus, it reuses existing resources before spinning up new ones. So early adopters cut compute costs by up to 85%. When you hear us saying that we purpose-built infrastructure for this next generation of the web, Fluid is a big part of that. Everyone wants to talk about what agents can do. Fewer people want to talk about how complex it gets. When they're running at scale, if your agentic product succeeds, usage goes up. If usage goes up, that profile matters. Infrastructure choices matter a lot more than many teams realize at the beginning. Go-to-market is getting closer to consulting than sales. The executives I'm talking to right now aren't asking me to pitch them on Brusseff; they're asking me to help them figure out. Where to start with agentic AI, what best practices look like, and what architecture should be— what breaks at scale. Production scale is what reveals whether architecture is actually durable. That's one of the reasons we think there is a significant difference between building an agent demo and building something in production at scale. So to recap, one, Build your developer surface area now. APIs, MPC servers, webhooks. The things that let your product be composed into an agentic workflow without a human in the loop. The companies that win in the agentic era will be the ones whose products are in the stack. The ones whose composable API layer won't— the ones who aren't won't have the composable API layer to be called. 2, invest in your data foundation. The knowledge base, the clean data warehouse, the semantic layer. None of it is exciting to build, but all of it is load-bearing. The agents you build will only be as good as the data underneath them. And as we learn, putting that data in front of smart people that make the data will make the data better itself, not just the agent that uses it. And 3, the average builder on your team today should be able to outship any vendor who's trying to sell you the same outcome. And if they can't, you can start experimenting today with a few hours carved out of the week. That's the new build versus buy. I truly believe that the companies that treat their go-to-market as a product, that document it, design it, iterate, and then automate it piece by piece are the ones that will end up on the right side of the shipped to agents. That's what we're building at Vercel, and we hope you build the same too.
