How We Solved Agent Building — Andrew Qu, Vercel

Hey everyone, thanks for coming. I'm

Andrew. I'm the chief of software at

Verscell

and I'm here to talk to you about how we

solved agent building at Verscell. I'm

the chief of software. So I work on a

mix of internal engineering, external

experimentation, and generally being at

the frontier and building new libraries,

frameworks, and technologies. For those

of you that don't know Verscell,

Verscell builds a gentic infrastructure

so people can build what's next. We get

started in the web world helping people

ship websites and web apps without

having to worry about the infrastructure

that doesn't make their app any better.

It can scale to a million and scale down

to zero effortlessly. But we're seeing a

change in what people want to build. You

know, people started by building pages,

but now we see them want to build

agents. And we've been embarking on a

similar journey to make it easy for

people to build agents and agentic

applications easier. We built this thing

called the AIDK. So instead of needing

to switch out 300 400 lines of provider

specific code, you're just going to

switch out one line of code and we have

the same model interface underlying for

all these different providers.

We built a lot of other tools to make it

easier to have model fallbacks, secure

code execution, better pricing when it's

inactive and waiting for responses, as

well as for durability and resumability.

And I'm here to talk to you about how I

went on this crazy experiment roughly a

year ago that led to a aentic explosion

at Verscell and led to a really cool

thing that we built recently

about uh this is 1980. Uh, Bill Gates

before my time had this quote saying he

imagined there would be a computer on

every desk and in every home. You know,

that was probably pretty contrarian then

and today it seems like very normal to

have that happen. And me and the CTO had

this thought, you know, instead of a

computer on every desk, could we

potentially have an agent on every desk?

You know, today we only really use

agents for coding and technical

workloads, but we're starting to see

expansion into things like design,

product management, and other verticals.

And this was maybe about a year ago, so

I would say I'm pretty early to this,

but that was when it was like sonnet 4

and things weren't as sophisticated as

they were today. And I tried to actually

explore this out, see what we could do

about it. I went around to various job

functions at Verscell, marketing, sales,

finance, legal, and I asked them, what

do you hate most about your job? And the

most compelling use case I heard was

that the data team, they were growing.

They were a very lean team, but Versel

was growing faster. You know, they had

so much more data from customers,

analytics, metrics, sales. They just had

to keep on aggregating and keep on

making available for themselves to use.

And at this time, if you think about

what the data science people ever have

to do, whenever someone from marketing

or sales has a question about a customer

or product, the data science team has to

drop everything they're doing, write the

query, process it, do an analysis, and

come back with some recommendation on

what to do. And this was really killer

to productivity. You know, the data team

did not want to drop everything and just

write queries all day. And so I worked

with our VP of data to try to build a

better way for them to operate this way.

And so if you think about the very first

thing you would ever do if you want to

try to use AI to solve a problem, you

may just build like a huge mega prompt.

You know, you just have a question, you

pass into an LM, you have it respond,

and that's it. You know, this was how

the first version really looked.

Honestly, I asked them for a dump of of

the snowflake schema. I pasted it into a

system prompt with a question and then

when it generated SQL I actually copy

and pasted that in and just ran it

myself. You know I just want to see are

the models good enough today in order to

write valid SQL given some decent

structure. And I would say this gave us

a little bit of confidence that you know

models today aren't that good but maybe

we can harness engineer or make the

context around it a little better and

give us some more guardrails to operate

a little better.

And so if you actually think about what

a data scientist actually needs to do

when they get a question, you know, they

have to process the question, they may

have to explore the semantic layer and

actually figure out what the join

patterns are. They will actually go and

execute the SQL. They may go back and do

that again if the SQL did not execute or

was too expensive. And they'll

eventually report on it, including

visualize the data, maybe write some

paragraphs, maybe do a retro, maybe do

some other stuff.

And so if you think about those

different phases, me and the VP of data

tried to sit down and map those out into

specific agent workloads. And so the

second version of this data science

agent uh called D0. I'm going to

reference D0 from now on is you ask a

question. We have a query agent that

passes on a query to the planning agent

that will then have an execution agent

etc. And if you chain all of these

together, you actually get something

that looks like this where each agent

has a very dedicated system prompt

focused to what that does with tools

scoped to exactly that function. So

example here, you can see that for the

first one, the planning agent has a read

entity YAML and a and a search schemas

tool. And so it will only use those

capabilities until it has an answer to

pass on to the planning agent and then

to the SQL agent and then to reporting.

And this was getting better. You know,

we were able to get away from having to

copy and paste a SQL and have to come

back and report on it. It was now

actually doing like the end to end loop

from question to answer.

But we started hitting some walls with

this architecture. And around this time

we came to the conclusion that you know

what you actually need is you need one

agent with all the mega context within

it and for it to sort of manage its own

memory. You know this was around the

time when we realized that you want to

actually have the agent be able to look

back on what it's done sort of reflect

and figure out the steps that got to get

here. And with the previous model you

may have noticed that the only thing

that the next agent gets is a summary

and a small snippet of the previous

thing that was done. Now this way you

can imagine that you have one mega agent

and internally it manages its own state.

At some points it's planning, some

points it's building, some points it's

executing and some points it's

reporting. And this is sort of what it

looked like. You know you have one big

AI call maybe max steps 100 and you give

it the ability to manage its own state

based on where it's at inside of its

execution journey. And so you can see

similar tools, you can see a similar

shape, but the best part about this is

if it ever ran to an error when

executing or joining, it could go back

and explore more or it could go and read

more and figure out what it was doing

wrong. And it was very good at this

point. We were pretty confident in the

actual system at hand and we actually

spread it to a few trusted members ever.

You know, this is a very powerful tool

and we didn't really want to put in the

hands of the wrong people or people that

were using very critical workloads. So,

we got to a few people's hands and the

immediate response was it was awful. You

know, we thought we were cooking. We

thought this was, you know, nailing 30%

of our evals, but we couldn't have

anticipated some of the questions that

were being asked. And for us to spend

more time manually mapping out some of

these scenarios, it didn't seem like a

very scalable way to do this.

And then claude code and opus 4.5 came

out. Well, more like Opus 4.5 came out

and it in tangent with claw code which

is so powerful. You know they sort of

unlocked the concept of a file system

agent and we on the side were like wow

clawed code and Opus 4.5 is basically

AGI compared to what we had before. You

know it would answer most of our

questions without even without even

missing a beat um compared to the

handgrown agent we had. And when we

tried to step back and wonder what we

were doing wrong and why this was so

much better, we realized that the big

unlock was that it was just a file

system. You know, we it had a very

minimal set of tools, list file, read

file, run bash, and we gave a few more

here for uh our own data agent use case.

But the biggest thing was it was able to

use the tools that agents are well

trained on and was able to explore and

write work where it needs to. you know,

we weren't giving it claw code was not

giving it a very prescriptive set of

tools. It was sort of just letting it go

wild and explore emergent behavior. And

so from this, we learned that you can

really just use a file system. You know,

we we saw the learnings from claw code

and how powerful it was given that it

just executes locally. And we tried to

rebuild it in a way that was very cloud

codeesque. You know, it was now going to

run in a sandbox. That sandbox would

dump the whole semantic layer into it.

You could the agent would be able to

grab, bash, read file, write file all

around to figure out what it needs and

we would just sprinkle a few tools on

top to make sure it could do everything

that is versel specific.

And this was actually the biggest unlock

ever. You know, the leap from single

agent to cloud code SDK and then from

cloud code SDK to file system agent in

general, fine-tuned or purpose-built for

our use case was an amazing leap. At

this point, we were starting to get

ready to give it away to more people at

Versell.

And at this point, the eval score

basically doubled. And I wrote this uh

this is basically how it looks. Um it's

very simple. You just give it a bash

tool. We have a nice helper called bash

tool on npm and you attach it to a

sandbox and you can attach files to the

sandbox for it to read, write and

execute.

And after this revelation and after I

saw that we were passing so many of the

questions that we failed to do before, I

wrote this banger blog post. It's uh

it's actually up today. And the week

that I wrote this, it was responsible

for 70% of our versel.com traffic. So

you know it's a banger. And after that,

the next logical step was that we want

to figure out the common use cases we

had. So by then we've already sort of

let a leash on all of our cell and we

were getting thousands of queries a day

from people wanting everything from

customer metrics sales metrics number

metrics npm downloads and it turns out

that a lot of these queries are actually

the same in shape you know there's only

so many ways you can do an aggregation

only so many ways you can look up a

product only so many ways you can do

billing info and so we actually have a

recurring job that takes the most recent

queries and tries to distill them into a

skill and right now we have roughly 100

skills that do a mix of aggregation all

the way through looking up specific data

about certain people. And we found this

very effective because if you think

about every new agent run, it sort of

just starts from nothing. You know,

there's really no pre-established

context besides, you know, the semantic

layer and the system prompt. But with a

skill, it already starts off with a lot

of contextual knowledge that has

otherwise already been done.

And this is roughly how it looks. It's

very similar to the previous one, but

the inclusion of a skills folder is

actually very powerful. Um, we also

built this tool at Verscell called

Skillsh. It's the most popular way to

find agent skills and run them yourself.

And I I'm saying all this because this

journey is something that most of you

may hit once in a while where you start

from something simple and you gradually

add complexity and you eventually hit a

system in which you can ship to prod.

And I'm telling you this because at

every step along building this agent,

someone Everell was agent curious and

they tried to fork off of my DZero agent

and build their own. And at every step,

we sort of had a better way to do

something that was not previously known.

And we were wondering like what if

people today could start from the very

last insight and not have to ever start

from just a simple prompt or from

reinventing best principles from first

principles.

And so we actually thought what if we

built the Nex.js for agents. For those

that don't know, Nex.js is a popular web

framework that Verscell built that

invented this thing of file system uh

framework defined infrastructure. You

don't have to worry about where things

go. You just have to write files in the

right conventions and it automatically

declares where they should go. Your

pages go to the CDN. Your serverless

functions go there. Your caching goes in

the middle. And we thought, you know,

building agents should be this simple.

You should only have to create a skills

folder, a tools folder, a channels

folder, and you should be able to just

declare these very easily. And the

framework should know exactly how to

make an agent out of it.

And that's why two weeks ago we released

Eve. Eve is a agent framework like the

next.js GS for agents where it's very

easy from just starting with a sample

template to having a fully agent ready

and being able to add in your own custom

knowledge, your own custom tools and

even integrated into the channels that

you are familiar with.

This is roughly what we think an agent

actually looks like. You know, an agent

has a runtime and it has channels. And

in that runtime, you're going to have

durability. You're going to want to run

things in an isolate environment. You're

going to want to call into different

models. And you're going to want to have

connections. And we built this with open

source in mind. You know, we built Eve

so you can plug in your own open source

adapters for Postgress, OpenAI's uh

responses API, Docker, other connectors.

But we also made it incredibly easy to

deploy in Verscell. The only thing here

you see different is that everything

here is using a Verscell product that

we've been building over the years in

order to make it easy to build these

experiences. Versell workflows for

durability, sandbox for secure

execution, and Verscell connect,

something we just released to make it

easy to generate short-lived ODC tokens

for connections.

And we actually rewrote the whole D0ero

agent in Eve as we were building Eve and

from the convoluted structures behind

the scenes that you did not see from the

code. Um, this is roughly how the file

system looks. It's very simple. You have

a bunch of system instructions, a couple

skills, a couple tools, and it's very

easy to compose this into a real agent,

and it's very easy to iterate on. We

actually gave this out to a few beta

customers before we actually fully

released it two weeks ago at our London

event. And this one company that

partners closely with us, Aura. They've

rebuilt their agent that's sort of like

a mini claw to go and test people's

services. It goes to websites, installs

them, it tries to use them. And they've

seen incredible success on building

their own agent from the ground up using

Eve compared to using an off-the-shelf

cloud code. Fewer steps, better

successes, as well as better insights.

And when you deploy Eve to Verscell, you

get observability observability out of

the box. You can see here that you get

all the agent runs, you see all the tool

calls, you see each step it takes as

well as maybe some estimated costs and

some optimizations you could potentially

take.

And you can get start today at eve.dev.

You can just clone it and you can just

start a template, deploy easily,

self-host if you need. And the reason

why I bring this up is because I hope

that there will be more and more

business specific use case agents. You

know, before we built Ezero, we actually

battle tested a lot of the industry

well-funded startups that were doing

these vertical agents that were

dedicated to taking your Snowflake

instance and making it so their agent

could run Snowflake queries against it.

But we found out that what really makes

this agent good is it has a lot of very

specific uh company knowledge. You know,

the way that Versel is a web- based

company. We have a lot of customers that

have websites and web properties. That

goes a lot deeper into when you should

query for what and what things link to

what. And so a lot of these

off-the-shelf agents, they're great.

They're good to try, but I think if you

really want to get the most juice out of

a squeeze, you should really try to

build your own agent and add in as much

company specific knowledge as you can.

Today, you know, we've had 20 roughly

decently PMF agents adversel that range

from anything from marketing retros to

figure out who to reach out to to the

first ever red line of a contract when

legal sees a new negotiation all the way

to my data science agent helping with

with data queries. And that goes to show

that we ever have been very

agent-filled. You know, all of this

stuff is actually saving us a lot of

time. The data team has never been more

productive. They have more time to go

and improve the performance of

Snowflake, to add new data sources that

were missing, to fill in the gaps that

they previously did not have time to

because they were so busy writing

queries. And I think it's never been

easier for you at your big, small,

medium-sized company to sort of automate

away some of the things that you do not

want to do or some of the things that

you're spending too much time doing. You

know, I think a lot of HR, finance,

sales can be somewhat automated with

agents. And I think Eve is the best way

to build said agents today.

And these are my socials. Thank you all

for coming and listening. I'm Andrew and

I'll be around if you want to chat

outside.

>> [music]