How We Solved Agent Building — Andrew Qu, Vercel
Read the talk
From SQL Prompts to File System Agents at Vercel
Andrew Qu traces the development of Vercel’s data science agent: why scoped agent chains lost useful context, how a sandboxed file system improved its behavior, and how reusable skills carried company knowledge into new runs.
From a talk by Andrew Qu
At a glance
Ideas worth remembering
The target was the complete question-to-answer workflow. Generating SQL helped test model capability, but useful automation also required semantic exploration, execution, revision, and reporting.
Scoped agent chains automated the task, but summary-based handoffs limited access to earlier reasoning. A single agent retained state and could revisit exploration after execution or join errors.
Qu attributes a major improvement to familiar file operations and bash in a sandbox containing the semantic layer, supplemented by company-specific tools. He reports a roughly doubled evaluation score, without enough methodological detail to isolate the contribution of each change.
Skills preserve knowledge from recurring work across runs. A recurring job distilled recent queries into roughly 100 skills, giving new runs more context than the semantic layer and system prompt alone.
Eve packages the approach through skills, tools, and channels conventions. Its runtime addresses durability, isolated execution, models, and connections, while Vercel deployment adds visibility into runs, tool calls, steps, and estimated costs.
Company knowledge remains central to usefulness: an agent needs to understand business relationships and query choices as well as access data. Qu’s reported payoff is that focused agents free employees to improve systems, with the data team spending more time on performance and missing sources.
Making room for agent applications
Andrew Qu, Vercel’s chief of software, opens with the infrastructure problem behind the talk. His work spans internal engineering, external experiments, and new libraries and frameworks. Vercel’s original proposition was to let developers ship websites and applications without managing infrastructure that did not improve the application itself. He describes agent applications as the next workload for that approach.
The AI SDK supplies a common model interface across providers. Qu contrasts changing one line with replacing 300–400 lines of provider-specific code. He also identifies model fallbacks, secure code execution, pricing while an application waits for responses, durability, and resumability as supporting concerns. These conveniences provide the backdrop for his internal experiment; they do not yet explain how an agent should reason through a business task.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Finding a task worth delegating
Qu and Vercel’s CTO considered whether the idea of a computer on every desk could become an agent on every desk. Rather than beginning with a general assistant, Qu asked people in marketing, sales, finance, and legal what they disliked most about their jobs. The question directed the experiment toward recurring work that employees wanted help completing.
The strongest candidate came from the data team. It was lean and growing more slowly than the company, while customer data, analytics, metrics, and sales information continued to accumulate. Keeping that information aggregated and available already required substantial work.
Each customer or product question from marketing or sales interrupted that work. A data scientist had to write a query, process its output, analyze the result, and return a recommendation. The target therefore extended beyond SQL generation: it was the whole path from a business question to an answer. Qu worked with the VP of data to reduce these interruptions so the team could spend less of its day answering individual requests.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Testing SQL generation with a large prompt
The first prototype used a large prompt. Qu obtained a dump of the Snowflake schema, pasted it into a system prompt, and supplied a question. When the model returned SQL, he copied it into the database interface and ran it himself. This was a limited capability test: could the model write valid SQL when given useful structure? Execution and the surrounding workflow still depended on a person.
The results gave him enough confidence to continue, but not enough to regard the model as reliable on its own. He saw opportunities to improve the context, the harness around the model, and its guardrails. A schema could help it produce SQL, but the broader task required more than knowing which tables and columns existed.
Qu breaks that broader task into the actions a data scientist performs. They interpret the question, explore the semantic layer to find join patterns, execute SQL, and try again if execution fails or the query is too expensive. Finally, they report the findings through visualizations and written analysis. This description makes revision part of the job: a generated query is an intermediate step that may need to change after execution.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Automating the workflow with scoped agents
The second version, called D0, mapped the phases of data work into separate agent workloads. A question moved through agents responsible for querying, planning, execution, and reporting. Each agent had a dedicated system prompt and tools restricted to its function. The architecture expressed the workflow through explicit handoffs between specialists.
For example, the schema-exploration stage could read entity YAML and search schemas. It used those capabilities until it had an answer to pass onward; subsequent stages handled SQL and reporting. This version removed Qu’s manual copying and execution of SQL and completed the loop from question to answer. Its immediate achievement was end-to-end automation through narrow responsibilities.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Keeping the reasoning history in one agent
The chain eventually reached a limit: the next agent received only a summary and a small snippet of the preceding work. Qu wanted the system to look back at what it had done, reflect on the path it had taken, and choose what to do next. The team replaced the chain with one agent that retained the broader context and managed its own state.
Planning, building, execution, and reporting became activities within the same agent’s run. Qu describes one large AI call with a possible maximum of 100 steps and tools similar to those used previously. The practical advantage was recovery: if execution or a join failed, the agent could return to exploration, read more information, and reconsider what it had misunderstood. It could move backward through the work while retaining the history that explained the failure.
Confidence in that behavior led to a small rollout among trusted users. Qu deliberately limited access because the tool was powerful and he did not want early use on very critical workloads. The response was nevertheless poor. The team had been encouraged by passing 30% of its evaluations, but users asked questions it had not anticipated. Manually mapping more scenarios did not look scalable. The rollout exposed a gap between success on the team’s existing questions and usefulness across the questions employees actually brought.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Giving the agent a file system to explore
A more capable model used with Claude Code gave Qu a different reference point. It answered many of the questions that troubled the custom agent. His explanation for the improvement centered on its environment: a file system and a small set of familiar operations, including listing files, reading files, and running bash. He argued that models were well trained to use these tools and could explore and write work as needed without a highly prescriptive set of task-specific operations.
The team rebuilt the data agent around that pattern. It ran in a sandbox containing the whole semantic layer. The agent could use bash and read and write files while working out what information it needed. A few additional tools supplied Vercel-specific capabilities. This changed how context was available: the agent could investigate material in its working environment rather than depend entirely on a predetermined sequence of specialized tool calls.
Qu reports that the evaluation score roughly doubled after this progression and that the agent began passing many questions it had previously failed. The implementation he describes is small: connect a bash tool to a sandbox and attach files that the agent can read, write, and execute. The result supports his enthusiasm for the approach, but the talk does not specify the evaluation set, scoring method, or an experiment that separates the effects of the model change from those of the harness.
The improvement encouraged broader distribution within Vercel and a public account of the work. Qu says his blog post accounted for 70% of traffic to Vercel’s website during the week he wrote it. That figure describes the attention the approach attracted; the technical evidence he offers remains the reported evaluation improvement and newly successful questions.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Carrying recurring work into the next run
Broader use produced thousands of queries a day, covering customer metrics, sales metrics, npm downloads, and other information. Many differed in their subject while sharing the same shape. Aggregations, product lookups, and billing requests repeatedly required similar work. Those recurring patterns became candidates for reusable skills.
A recurring job takes recent queries and tries to distill them into skills. Qu reports roughly 100 skills, ranging from aggregation to looking up specific information about people. Their purpose is to preserve useful context from work already completed. Without them, a new run starts with the semantic layer and system prompt; with them, it also has accumulated knowledge about familiar tasks.
The visible structural change is the addition of a skills folder to the existing file system approach. Qu also mentions a Vercel tool for discovering and running agent skills. The mechanism he explains is reuse of contextual knowledge, rather than a described retraining process. He does not detail how the recurring job validates a distilled skill or decides which skills a particular question should use.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Turning the working pattern into Eve
As D0 evolved, other employees repeatedly forked it to build their own agents. Each fork could begin from an earlier design and miss an insight discovered later. Qu wanted new builders to start from the most developed pattern instead of repeating the journey from a simple prompt through successive architectures. That became the motivation for a framework.
His analogy is Next.js and framework-defined infrastructure. In his account, file conventions let developers declare application structure while the framework determines where pages, functions, and caching belong. For agents, the proposed conventions are skills, tools, and channels folders. The builder supplies those pieces, and the framework knows how to compose them into an agent.
Qu presents Eve as the framework released two weeks before the talk. A sample template provides a starting agent that builders can extend with their own knowledge, custom tools, and familiar communication channels. His underlying model separates the runtime from the channels. The runtime needs durability, isolated execution, access to different models, and connections to other systems.
Eve is designed to accept open source adapters, with examples including OpenAI’s Responses API, Docker, database adapters, and other connectors. Qu also describes a convenient Vercel deployment path: workflows provide durability, a sandbox provides secure execution, and Vercel Connect generates short-lived tokens for connections. The framework therefore offers an adaptable runtime alongside an integrated deployment option. The talk names the responsibilities of these components without explaining their persistence, isolation, or token protocols in detail.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Composing agents and inspecting their runs
The team rewrote D0 in Eve while developing the framework. Qu describes the resulting file structure as system instructions, skills, and tools that are easy to compose and iterate on. This is the maintainability claim behind the conventions: builders can work with recognizable pieces of the agent instead of the more convoluted structures used previously.
Before release, beta customers tried the framework. One partner rebuilt an agent that tests services by visiting websites, installing them, and attempting to use them. Qu reports fewer steps, better success, and better insights than the partner obtained with an off-the-shelf coding agent. These are qualitative results: he supplies neither numerical comparisons nor a description of the test conditions.
Deployment on Vercel also supplies observability. Qu describes visibility into agent runs, tool calls, individual steps, estimated costs, and possible optimizations. Those views make the work performed inside a run inspectable, rather than exposing only its final answer. He closes the product introduction with a template-based starting path and the option to self-host.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Why company knowledge determines usefulness
Qu’s closing argument returns to business-specific agents. Before building its own data agent, Vercel tested products designed to connect to a Snowflake instance and run queries against it. He says the distinguishing ingredient in Vercel’s agent was detailed company knowledge. Vercel’s customers have websites and web properties, and useful analysis depends on understanding when to query particular information and how those entities relate. Access to the database alone does not supply that understanding.
He regards off-the-shelf agents as useful to try, but recommends building a custom agent and adding as much company-specific knowledge as possible when seeking better results. This recommendation follows from his account of data relationships and query choices. It is an argument for fitting an agent to a particular business, rather than evidence that every organization must build its own.
Qu reports roughly 20 internal agents that have found useful roles. Their tasks include marketing retrospectives and deciding whom to contact, producing an initial contract redline for a new legal negotiation, and answering data queries. The examples remain bounded pieces of work. An initial redline is one stage of a negotiation, just as a data query is one contribution to a larger business decision.
The productivity benefit he emphasizes is what the data team can do with the time recovered. Instead of continually writing requested queries, it can improve Snowflake performance, add missing data sources, and fill gaps it previously lacked time to address. He reports substantial time savings and greater productivity, but gives no measured hours saved. The concrete change in his account is a shift from responding to interruptions toward improving the underlying data system.
Qu ends by encouraging companies of different sizes to automate work that employees dislike or spend too much time doing. He identifies HR, finance, and sales as areas where some work could be automated and recommends Eve as his preferred way to build those agents. The recommendation is his closing judgment, extending the internal experience into an invitation to build similarly focused business tools. He then thanks the audience and offers to continue the conversation outside.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Read the complete timestamped transcript
- 0:12
Hey everyone, thanks for coming. I'm
- 0:15
Andrew. I'm the chief of software at
- 0:17
Verscell
- 0:19
and I'm here to talk to you about how we
- 0:21
solved agent building at Verscell. I'm
- 0:24
the chief of software. So I work on a
- 0:26
mix of internal engineering, external
- 0:28
experimentation, and generally being at
- 0:30
the frontier and building new libraries,
- 0:32
frameworks, and technologies. For those
- 0:34
of you that don't know Verscell,
- 0:37
Verscell builds a gentic infrastructure
- 0:39
so people can build what's next. We get
- 0:42
started in the web world helping people
- 0:43
ship websites and web apps without
- 0:46
having to worry about the infrastructure
- 0:47
that doesn't make their app any better.
- 0:49
It can scale to a million and scale down
- 0:50
to zero effortlessly. But we're seeing a
- 0:53
change in what people want to build. You
- 0:55
know, people started by building pages,
- 0:57
but now we see them want to build
- 0:58
agents. And we've been embarking on a
- 1:00
similar journey to make it easy for
- 1:02
people to build agents and agentic
- 1:05
applications easier. We built this thing
- 1:08
called the AIDK. So instead of needing
- 1:10
to switch out 300 400 lines of provider
- 1:13
specific code, you're just going to
- 1:14
switch out one line of code and we have
- 1:16
the same model interface underlying for
- 1:18
all these different providers.
- 1:21
We built a lot of other tools to make it
- 1:22
easier to have model fallbacks, secure
- 1:25
code execution, better pricing when it's
- 1:27
inactive and waiting for responses, as
- 1:29
well as for durability and resumability.
- 1:32
And I'm here to talk to you about how I
- 1:35
went on this crazy experiment roughly a
- 1:37
year ago that led to a aentic explosion
- 1:41
at Verscell and led to a really cool
- 1:43
thing that we built recently
- 1:46
about uh this is 1980. Uh, Bill Gates
- 1:49
before my time had this quote saying he
- 1:52
imagined there would be a computer on
- 1:53
every desk and in every home. You know,
- 1:55
that was probably pretty contrarian then
- 1:57
and today it seems like very normal to
- 2:00
have that happen. And me and the CTO had
- 2:03
this thought, you know, instead of a
- 2:06
computer on every desk, could we
- 2:08
potentially have an agent on every desk?
- 2:10
You know, today we only really use
- 2:13
agents for coding and technical
- 2:15
workloads, but we're starting to see
- 2:17
expansion into things like design,
- 2:19
product management, and other verticals.
- 2:22
And this was maybe about a year ago, so
- 2:24
I would say I'm pretty early to this,
- 2:25
but that was when it was like sonnet 4
- 2:27
and things weren't as sophisticated as
- 2:29
they were today. And I tried to actually
- 2:32
explore this out, see what we could do
- 2:34
about it. I went around to various job
- 2:36
functions at Verscell, marketing, sales,
- 2:39
finance, legal, and I asked them, what
- 2:41
do you hate most about your job? And the
- 2:45
most compelling use case I heard was
- 2:47
that the data team, they were growing.
- 2:50
They were a very lean team, but Versel
- 2:52
was growing faster. You know, they had
- 2:54
so much more data from customers,
- 2:56
analytics, metrics, sales. They just had
- 2:59
to keep on aggregating and keep on
- 3:01
making available for themselves to use.
- 3:05
And at this time, if you think about
- 3:07
what the data science people ever have
- 3:08
to do, whenever someone from marketing
- 3:10
or sales has a question about a customer
- 3:12
or product, the data science team has to
- 3:15
drop everything they're doing, write the
- 3:17
query, process it, do an analysis, and
- 3:19
come back with some recommendation on
- 3:21
what to do. And this was really killer
- 3:24
to productivity. You know, the data team
- 3:26
did not want to drop everything and just
- 3:28
write queries all day. And so I worked
- 3:29
with our VP of data to try to build a
- 3:31
better way for them to operate this way.
- 3:36
And so if you think about the very first
- 3:37
thing you would ever do if you want to
- 3:39
try to use AI to solve a problem, you
- 3:41
may just build like a huge mega prompt.
- 3:43
You know, you just have a question, you
- 3:46
pass into an LM, you have it respond,
- 3:48
and that's it. You know, this was how
- 3:50
the first version really looked.
- 3:51
Honestly, I asked them for a dump of of
- 3:54
the snowflake schema. I pasted it into a
- 3:57
system prompt with a question and then
- 3:59
when it generated SQL I actually copy
- 4:01
and pasted that in and just ran it
- 4:02
myself. You know I just want to see are
- 4:04
the models good enough today in order to
- 4:06
write valid SQL given some decent
- 4:09
structure. And I would say this gave us
- 4:11
a little bit of confidence that you know
- 4:13
models today aren't that good but maybe
- 4:15
we can harness engineer or make the
- 4:17
context around it a little better and
- 4:19
give us some more guardrails to operate
- 4:21
a little better.
- 4:22
And so if you actually think about what
- 4:24
a data scientist actually needs to do
- 4:25
when they get a question, you know, they
- 4:27
have to process the question, they may
- 4:29
have to explore the semantic layer and
- 4:31
actually figure out what the join
- 4:32
patterns are. They will actually go and
- 4:34
execute the SQL. They may go back and do
- 4:37
that again if the SQL did not execute or
- 4:39
was too expensive. And they'll
- 4:40
eventually report on it, including
- 4:42
visualize the data, maybe write some
- 4:44
paragraphs, maybe do a retro, maybe do
- 4:46
some other stuff.
- 4:48
And so if you think about those
- 4:49
different phases, me and the VP of data
- 4:51
tried to sit down and map those out into
- 4:53
specific agent workloads. And so the
- 4:55
second version of this data science
- 4:57
agent uh called D0. I'm going to
- 4:59
reference D0 from now on is you ask a
- 5:02
question. We have a query agent that
- 5:04
passes on a query to the planning agent
- 5:06
that will then have an execution agent
- 5:08
etc. And if you chain all of these
- 5:11
together, you actually get something
- 5:12
that looks like this where each agent
- 5:14
has a very dedicated system prompt
- 5:16
focused to what that does with tools
- 5:18
scoped to exactly that function. So
- 5:20
example here, you can see that for the
- 5:23
first one, the planning agent has a read
- 5:25
entity YAML and a and a search schemas
- 5:29
tool. And so it will only use those
- 5:32
capabilities until it has an answer to
- 5:34
pass on to the planning agent and then
- 5:36
to the SQL agent and then to reporting.
- 5:38
And this was getting better. You know,
- 5:40
we were able to get away from having to
- 5:42
copy and paste a SQL and have to come
- 5:45
back and report on it. It was now
- 5:46
actually doing like the end to end loop
- 5:48
from question to answer.
- 5:51
But we started hitting some walls with
- 5:54
this architecture. And around this time
- 5:56
we came to the conclusion that you know
- 5:58
what you actually need is you need one
- 5:59
agent with all the mega context within
- 6:01
it and for it to sort of manage its own
- 6:04
memory. You know this was around the
- 6:06
time when we realized that you want to
- 6:10
actually have the agent be able to look
- 6:11
back on what it's done sort of reflect
- 6:13
and figure out the steps that got to get
- 6:15
here. And with the previous model you
- 6:17
may have noticed that the only thing
- 6:18
that the next agent gets is a summary
- 6:21
and a small snippet of the previous
- 6:22
thing that was done. Now this way you
- 6:24
can imagine that you have one mega agent
- 6:27
and internally it manages its own state.
- 6:29
At some points it's planning, some
- 6:31
points it's building, some points it's
- 6:32
executing and some points it's
- 6:33
reporting. And this is sort of what it
- 6:36
looked like. You know you have one big
- 6:38
AI call maybe max steps 100 and you give
- 6:42
it the ability to manage its own state
- 6:44
based on where it's at inside of its
- 6:46
execution journey. And so you can see
- 6:48
similar tools, you can see a similar
- 6:50
shape, but the best part about this is
- 6:51
if it ever ran to an error when
- 6:53
executing or joining, it could go back
- 6:55
and explore more or it could go and read
- 6:57
more and figure out what it was doing
- 6:59
wrong. And it was very good at this
- 7:01
point. We were pretty confident in the
- 7:04
actual system at hand and we actually
- 7:06
spread it to a few trusted members ever.
- 7:08
You know, this is a very powerful tool
- 7:10
and we didn't really want to put in the
- 7:11
hands of the wrong people or people that
- 7:12
were using very critical workloads. So,
- 7:15
we got to a few people's hands and the
- 7:17
immediate response was it was awful. You
- 7:18
know, we thought we were cooking. We
- 7:20
thought this was, you know, nailing 30%
- 7:22
of our evals, but we couldn't have
- 7:24
anticipated some of the questions that
- 7:25
were being asked. And for us to spend
- 7:27
more time manually mapping out some of
- 7:29
these scenarios, it didn't seem like a
- 7:32
very scalable way to do this.
- 7:35
And then claude code and opus 4.5 came
- 7:39
out. Well, more like Opus 4.5 came out
- 7:41
and it in tangent with claw code which
- 7:43
is so powerful. You know they sort of
- 7:46
unlocked the concept of a file system
- 7:48
agent and we on the side were like wow
- 7:52
clawed code and Opus 4.5 is basically
- 7:55
AGI compared to what we had before. You
- 7:57
know it would answer most of our
- 7:58
questions without even without even
- 8:02
missing a beat um compared to the
- 8:03
handgrown agent we had. And when we
- 8:05
tried to step back and wonder what we
- 8:07
were doing wrong and why this was so
- 8:08
much better, we realized that the big
- 8:11
unlock was that it was just a file
- 8:13
system. You know, we it had a very
- 8:15
minimal set of tools, list file, read
- 8:17
file, run bash, and we gave a few more
- 8:20
here for uh our own data agent use case.
- 8:24
But the biggest thing was it was able to
- 8:26
use the tools that agents are well
- 8:28
trained on and was able to explore and
- 8:30
write work where it needs to. you know,
- 8:32
we weren't giving it claw code was not
- 8:35
giving it a very prescriptive set of
- 8:36
tools. It was sort of just letting it go
- 8:38
wild and explore emergent behavior. And
- 8:41
so from this, we learned that you can
- 8:43
really just use a file system. You know,
- 8:45
we we saw the learnings from claw code
- 8:47
and how powerful it was given that it
- 8:49
just executes locally. And we tried to
- 8:52
rebuild it in a way that was very cloud
- 8:54
codeesque. You know, it was now going to
- 8:56
run in a sandbox. That sandbox would
- 8:58
dump the whole semantic layer into it.
- 9:00
You could the agent would be able to
- 9:02
grab, bash, read file, write file all
- 9:04
around to figure out what it needs and
- 9:06
we would just sprinkle a few tools on
- 9:07
top to make sure it could do everything
- 9:08
that is versel specific.
- 9:12
And this was actually the biggest unlock
- 9:14
ever. You know, the leap from single
- 9:17
agent to cloud code SDK and then from
- 9:19
cloud code SDK to file system agent in
- 9:22
general, fine-tuned or purpose-built for
- 9:25
our use case was an amazing leap. At
- 9:27
this point, we were starting to get
- 9:28
ready to give it away to more people at
- 9:31
Versell.
- 9:32
And at this point, the eval score
- 9:35
basically doubled. And I wrote this uh
- 9:37
this is basically how it looks. Um it's
- 9:39
very simple. You just give it a bash
- 9:41
tool. We have a nice helper called bash
- 9:42
tool on npm and you attach it to a
- 9:45
sandbox and you can attach files to the
- 9:46
sandbox for it to read, write and
- 9:48
execute.
- 9:50
And after this revelation and after I
- 9:52
saw that we were passing so many of the
- 9:54
questions that we failed to do before, I
- 9:56
wrote this banger blog post. It's uh
- 9:58
it's actually up today. And the week
- 10:01
that I wrote this, it was responsible
- 10:02
for 70% of our versel.com traffic. So
- 10:05
you know it's a banger. And after that,
- 10:09
the next logical step was that we want
- 10:12
to figure out the common use cases we
- 10:14
had. So by then we've already sort of
- 10:16
let a leash on all of our cell and we
- 10:19
were getting thousands of queries a day
- 10:21
from people wanting everything from
- 10:23
customer metrics sales metrics number
- 10:25
metrics npm downloads and it turns out
- 10:28
that a lot of these queries are actually
- 10:30
the same in shape you know there's only
- 10:31
so many ways you can do an aggregation
- 10:33
only so many ways you can look up a
- 10:34
product only so many ways you can do
- 10:36
billing info and so we actually have a
- 10:38
recurring job that takes the most recent
- 10:40
queries and tries to distill them into a
- 10:42
skill and right now we have roughly 100
- 10:44
skills that do a mix of aggregation all
- 10:47
the way through looking up specific data
- 10:49
about certain people. And we found this
- 10:51
very effective because if you think
- 10:53
about every new agent run, it sort of
- 10:55
just starts from nothing. You know,
- 10:56
there's really no pre-established
- 10:58
context besides, you know, the semantic
- 11:00
layer and the system prompt. But with a
- 11:02
skill, it already starts off with a lot
- 11:04
of contextual knowledge that has
- 11:05
otherwise already been done.
- 11:09
And this is roughly how it looks. It's
- 11:11
very similar to the previous one, but
- 11:12
the inclusion of a skills folder is
- 11:14
actually very powerful. Um, we also
- 11:16
built this tool at Verscell called
- 11:17
Skillsh. It's the most popular way to
- 11:19
find agent skills and run them yourself.
- 11:23
And I I'm saying all this because this
- 11:25
journey is something that most of you
- 11:27
may hit once in a while where you start
- 11:29
from something simple and you gradually
- 11:30
add complexity and you eventually hit a
- 11:32
system in which you can ship to prod.
- 11:35
And I'm telling you this because at
- 11:37
every step along building this agent,
- 11:39
someone Everell was agent curious and
- 11:42
they tried to fork off of my DZero agent
- 11:45
and build their own. And at every step,
- 11:47
we sort of had a better way to do
- 11:49
something that was not previously known.
- 11:51
And we were wondering like what if
- 11:53
people today could start from the very
- 11:55
last insight and not have to ever start
- 11:57
from just a simple prompt or from
- 12:00
reinventing best principles from first
- 12:03
principles.
- 12:04
And so we actually thought what if we
- 12:06
built the Nex.js for agents. For those
- 12:09
that don't know, Nex.js is a popular web
- 12:11
framework that Verscell built that
- 12:13
invented this thing of file system uh
- 12:16
framework defined infrastructure. You
- 12:18
don't have to worry about where things
- 12:19
go. You just have to write files in the
- 12:22
right conventions and it automatically
- 12:24
declares where they should go. Your
- 12:26
pages go to the CDN. Your serverless
- 12:28
functions go there. Your caching goes in
- 12:30
the middle. And we thought, you know,
- 12:32
building agents should be this simple.
- 12:34
You should only have to create a skills
- 12:35
folder, a tools folder, a channels
- 12:37
folder, and you should be able to just
- 12:39
declare these very easily. And the
- 12:40
framework should know exactly how to
- 12:42
make an agent out of it.
- 12:45
And that's why two weeks ago we released
- 12:46
Eve. Eve is a agent framework like the
- 12:49
next.js GS for agents where it's very
- 12:51
easy from just starting with a sample
- 12:53
template to having a fully agent ready
- 12:56
and being able to add in your own custom
- 12:57
knowledge, your own custom tools and
- 12:59
even integrated into the channels that
- 13:01
you are familiar with.
- 13:04
This is roughly what we think an agent
- 13:05
actually looks like. You know, an agent
- 13:07
has a runtime and it has channels. And
- 13:09
in that runtime, you're going to have
- 13:10
durability. You're going to want to run
- 13:12
things in an isolate environment. You're
- 13:14
going to want to call into different
- 13:15
models. And you're going to want to have
- 13:16
connections. And we built this with open
- 13:19
source in mind. You know, we built Eve
- 13:21
so you can plug in your own open source
- 13:22
adapters for Postgress, OpenAI's uh
- 13:25
responses API, Docker, other connectors.
- 13:28
But we also made it incredibly easy to
- 13:30
deploy in Verscell. The only thing here
- 13:32
you see different is that everything
- 13:33
here is using a Verscell product that
- 13:35
we've been building over the years in
- 13:36
order to make it easy to build these
- 13:38
experiences. Versell workflows for
- 13:40
durability, sandbox for secure
- 13:42
execution, and Verscell connect,
- 13:44
something we just released to make it
- 13:45
easy to generate short-lived ODC tokens
- 13:48
for connections.
- 13:51
And we actually rewrote the whole D0ero
- 13:53
agent in Eve as we were building Eve and
- 13:56
from the convoluted structures behind
- 13:57
the scenes that you did not see from the
- 13:59
code. Um, this is roughly how the file
- 14:01
system looks. It's very simple. You have
- 14:02
a bunch of system instructions, a couple
- 14:05
skills, a couple tools, and it's very
- 14:07
easy to compose this into a real agent,
- 14:09
and it's very easy to iterate on. We
- 14:12
actually gave this out to a few beta
- 14:13
customers before we actually fully
- 14:15
released it two weeks ago at our London
- 14:16
event. And this one company that
- 14:18
partners closely with us, Aura. They've
- 14:20
rebuilt their agent that's sort of like
- 14:22
a mini claw to go and test people's
- 14:25
services. It goes to websites, installs
- 14:27
them, it tries to use them. And they've
- 14:30
seen incredible success on building
- 14:33
their own agent from the ground up using
- 14:35
Eve compared to using an off-the-shelf
- 14:37
cloud code. Fewer steps, better
- 14:40
successes, as well as better insights.
- 14:45
And when you deploy Eve to Verscell, you
- 14:47
get observability observability out of
- 14:49
the box. You can see here that you get
- 14:50
all the agent runs, you see all the tool
- 14:52
calls, you see each step it takes as
- 14:55
well as maybe some estimated costs and
- 14:56
some optimizations you could potentially
- 14:58
take.
- 15:00
And you can get start today at eve.dev.
- 15:03
You can just clone it and you can just
- 15:04
start a template, deploy easily,
- 15:06
self-host if you need. And the reason
- 15:08
why I bring this up is because I hope
- 15:10
that there will be more and more
- 15:12
business specific use case agents. You
- 15:15
know, before we built Ezero, we actually
- 15:17
battle tested a lot of the industry
- 15:20
well-funded startups that were doing
- 15:22
these vertical agents that were
- 15:24
dedicated to taking your Snowflake
- 15:26
instance and making it so their agent
- 15:28
could run Snowflake queries against it.
- 15:31
But we found out that what really makes
- 15:33
this agent good is it has a lot of very
- 15:36
specific uh company knowledge. You know,
- 15:39
the way that Versel is a web- based
- 15:41
company. We have a lot of customers that
- 15:43
have websites and web properties. That
- 15:45
goes a lot deeper into when you should
- 15:48
query for what and what things link to
- 15:50
what. And so a lot of these
- 15:52
off-the-shelf agents, they're great.
- 15:54
They're good to try, but I think if you
- 15:56
really want to get the most juice out of
- 15:57
a squeeze, you should really try to
- 15:58
build your own agent and add in as much
- 16:00
company specific knowledge as you can.
- 16:03
Today, you know, we've had 20 roughly
- 16:06
decently PMF agents adversel that range
- 16:09
from anything from marketing retros to
- 16:13
figure out who to reach out to to the
- 16:15
first ever red line of a contract when
- 16:18
legal sees a new negotiation all the way
- 16:20
to my data science agent helping with
- 16:22
with data queries. And that goes to show
- 16:26
that we ever have been very
- 16:27
agent-filled. You know, all of this
- 16:30
stuff is actually saving us a lot of
- 16:32
time. The data team has never been more
- 16:34
productive. They have more time to go
- 16:36
and improve the performance of
- 16:38
Snowflake, to add new data sources that
- 16:40
were missing, to fill in the gaps that
- 16:42
they previously did not have time to
- 16:43
because they were so busy writing
- 16:45
queries. And I think it's never been
- 16:48
easier for you at your big, small,
- 16:50
medium-sized company to sort of automate
- 16:53
away some of the things that you do not
- 16:55
want to do or some of the things that
- 16:56
you're spending too much time doing. You
- 16:58
know, I think a lot of HR, finance,
- 17:00
sales can be somewhat automated with
- 17:04
agents. And I think Eve is the best way
- 17:06
to build said agents today.
- 17:09
And these are my socials. Thank you all
- 17:11
for coming and listening. I'm Andrew and
- 17:13
I'll be around if you want to chat
- 17:15
outside.
- 17:31
>> [music]