Como resolvemos a construção de agentes — Andrew Qu, Vercel

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: How We Solved Agent Building — Andrew Qu, Vercel · Canal: AI Engineer · 17:11 · Assistir no YouTube

Tópicos: Agentes de IA, Automação de tarefas e workflows, Ferramentas de desenvolvimento com IA

Resumo

Andrew Qu descreve a evolução de um agente de dados interno da Vercel: de um mega prompt para agentes especializados, depois para um único agente com acesso a um sistema de arquivos e, por fim, para um agente que usa skills reutilizáveis. A experiência mostrou que um ambiente flexível, com ferramentas familiares e conhecimento específico da empresa, pode funcionar melhor do que fluxos rígidos ou soluções genéricas prontas. A partir dessas lições, a Vercel criou o framework Eve para facilitar a construção, a execução e o deploy de agentes. Qu defende que empresas construam agentes próprios para automatizar tarefas e aproveitar seu conhecimento interno.

Pontos-chave

A Vercel criou o AI SDK para oferecer uma interface comum entre provedores de modelos e facilitar recursos como fallback, execução segura de código e durabilidade.
O primeiro protótipo do agente de dados usava um mega prompt com o schema do Snowflake e servia para testar se os modelos conseguiam gerar SQL válido.
A arquitetura com agentes especializados em etapas distintas melhorou o fluxo, mas limitava o contexto disponível a cada agente.
Um único agente com estado próprio e acesso a um sistema de arquivos conseguiu explorar, executar, refletir sobre erros e tentar novamente.
Acesso a ferramentas simples e familiares, como listar e ler arquivos e executar bash, foi um avanço importante para o agente de dados.
A equipe passou a extrair skills reutilizáveis de consultas recorrentes, dando aos novos agentes conhecimento contextual já estruturado.
A Vercel criou Eve, um framework de agentes organizado em pastas de skills, tools e channels, com suporte a diferentes adaptadores e deploy na Vercel.
Segundo Qu, agentes próprios podem superar soluções genéricas quando incorporam o conhecimento específico e os processos de uma empresa.
Os agentes internos da Vercel automatizam tarefas de áreas como marketing, jurídico e ciência de dados, liberando tempo para trabalhos de maior impacto.

Capítulos

Início	Capítulo	Resumo
00:12	Da infraestrutura web à ideia de um agente em cada mesa	Qu apresenta a Vercel e explica por que a empresa começou a explorar agentes para diferentes funções de trabalho.
03:28	Construção e limites do primeiro agente de dados	A equipe testa a geração de SQL com um mega prompt e depois divide o trabalho entre agentes especializados.
07:08	O sistema de arquivos como avanço decisivo	Após resultados decepcionantes, a equipe se inspira em Claude Code e adota um agente com acesso flexível a arquivos e bash.
10:25	Skills reutilizáveis e a criação do Eve	A Vercel extrai skills de consultas recorrentes e transforma os aprendizados do agente em um framework para construir outros agentes.
13:01	Eve em uso e o valor do conhecimento específico	Qu descreve os recursos do Eve, exemplos de uso e os ganhos dos agentes internos que incorporam conhecimento da empresa.

Citações

Em vez de um computador em cada mesa, será que poderíamos ter um agente em cada mesa? — 01:52

O maior avanço foi ele ser simplesmente um sistema de arquivos. — 08:13

E se as pessoas pudessem começar pelo último insight, sem precisar reinventar os princípios desde o início? — 11:29

Se você quer tirar o máximo proveito, deveria tentar construir seu próprio agente e adicionar o máximo possível de conhecimento específico da empresa. — 15:36

Conceitos e entidades

Andrew Qu (pessoa): Apresentador da palestra e responsável por relatar a evolução dos agentes internos da Vercel.
Vercel (empresa): Empresa que desenvolveu o agente de dados descrito e o framework Eve.
AI SDK (ferramenta): Kit de desenvolvimento apresentado como uma interface comum para trabalhar com diferentes provedores de modelos.
Snowflake (ferramenta): Plataforma de dados cujos schemas e consultas aparecem no caso de uso do agente de ciência de dados.
D0 (ferramenta): Nome dado ao agente de dados interno da Vercel descrito na palestra.
Claude Code (ferramenta): Ferramenta citada como referência de agente com acesso a um sistema de arquivos e ferramentas simples.
Opus 4.5 (modelo): Modelo mencionado junto de Claude Code como um avanço que influenciou a abordagem da equipe.
Skills.sh (ferramenta): Ferramenta da Vercel descrita como uma forma popular de encontrar e executar skills de agentes.
Eve (ferramenta): Framework da Vercel para estruturar e construir agentes com skills, ferramentas e canais.
Next.js (ferramenta): Framework da Vercel usado como analogia para explicar a proposta de organização baseada em convenções do Eve.

Tradução completa (pt-BR)

00:12 Olá, pessoal. Obrigado por virem. Sou Andrew. Sou o diretor de software da Vercel e estou aqui para falar sobre como resolvemos a construção de agents na Vercel. Sou o diretor de software. Então, trabalho com uma combinação de engenharia interna, experimentação externa e, de modo geral, com a fronteira da tecnologia, criando novas bibliotecas, frameworks e tecnologias. Para quem não conhece a Vercel, a Vercel cria infraestrutura agentic para que as pessoas possam construir o que vem a seguir. Começamos no mundo da web, ajudando as pessoas a

00:43 publicar sites e aplicações web sem precisar se preocupar com a infraestrutura, que não torna a aplicação delas melhor. Ela pode escalar para um milhão e reduzir até zero sem esforço. Mas estamos vendo uma mudança no que as pessoas querem construir. Sabe, as pessoas começaram construindo páginas, mas agora vemos que elas querem construir agents. E temos embarcado em uma jornada parecida para facilitar a criação de agents e aplicações agentic. Criamos algo chamado AI SDK. Então, em vez de precisar trocar 300 ou 400 linhas de código específico de cada provedor, você só precisa trocar uma linha de código, e temos

01:16 a mesma interface de modelo subjacente para todos esses provedores diferentes. Criamos muitas outras ferramentas para facilitar o uso de modelos alternativos, a execução segura de código, obter preços melhores quando ele está inativo e aguardando respostas, além de oferecer durabilidade e retomada. E estou aqui para contar como, há cerca de um ano, embarquei nesse experimento maluco que levou a uma explosão de aplicações agentic na Vercel e resultou em algo muito legal que criamos recentemente. Isso foi em 1980. Bill Gates, antes da minha época, disse que

01:52 imaginava que haveria um computador em cada mesa e em cada casa. Sabe, naquela época, isso provavelmente era uma ideia bem contrária ao senso comum, mas hoje parece muito normal. Eu e o CTO pensamos: em vez de um computador em cada mesa, será que poderíamos ter um agent em cada mesa? Hoje, usamos agents principalmente para programação e tarefas técnicas, mas estamos começando a ver a expansão para áreas como design, gestão de produtos e outros setores. E isso foi talvez há cerca de um ano, então

02:24 eu diria que cheguei bem cedo a isso, mas naquela época tínhamos o Sonnet 4, e as coisas não eram tão sofisticadas quanto são hoje. Tentei explorar de fato o que poderíamos fazer. Conversei com pessoas de várias áreas da Vercel: marketing, vendas, finanças, jurídico, e perguntei: o que vocês mais odeiam no trabalho? O caso de uso mais promissor que ouvi veio da equipe de dados. Ela estava crescendo. Era uma equipe bem enxuta, mas a Vercel estava crescendo mais rápido. Sabe, eles tinham muito mais dados de clientes,

02:56 análises, métricas e vendas. Eles precisavam continuar agregando esses dados e disponibilizando-os para uso próprio. E, naquela época, se você pensar no que as pessoas de ciência de dados precisam fazer, sempre que alguém de marketing ou vendas tem uma pergunta sobre um cliente ou produto, a equipe de ciência de dados precisa parar tudo o que está fazendo, escrever a consulta, processá-la, fazer uma análise e voltar com alguma recomendação sobre o que fazer. E isso prejudicava muito a produtividade. Sabe, a equipe de dados não queria parar tudo só para

03:28 escrever consultas o dia inteiro. Então, trabalhei com nosso VP de dados para tentar criar uma maneira melhor de fazer esse trabalho. Se você pensar na primeira coisa que faria para tentar usar IA para resolver um problema, talvez criasse um mega prompt enorme. Sabe, você faz uma pergunta, envia para um LLM, recebe uma resposta, e pronto. A primeira versão era basicamente assim. Para ser sincero, pedi a eles um despejo do esquema do Snowflake. Colei isso em um system prompt junto com uma pergunta e então

03:59 quando ele gerou SQL, copiei e colei o código e executei por conta própria. Sabe, eu só queria ver se os modelos já eram bons o suficiente para escrever SQL válido a partir de uma estrutura razoável. Eu diria que isso nos deu um pouco de confiança de que, sabe, os modelos de hoje não são tão bons, mas talvez pudéssemos fazer engenharia de harness ou melhorar um pouco o contexto ao redor e nos dar mais algumas proteções para trabalhar melhor. E, se você pensar no que uma pessoa de ciência de dados realmente precisa fazer quando recebe uma pergunta, sabe, ela precisa processar a pergunta, talvez

04:29 precise explorar a camada semântica e descobrir quais são os padrões de junção. Depois, ela executa o SQL. Talvez precise voltar e tentar de novo se o SQL não for executado ou for caro demais. Por fim, ela apresenta os resultados, incluindo a visualização dos dados, talvez escrevendo alguns parágrafos, talvez fazendo uma retrospectiva, talvez fazendo outras coisas. Então, pensando nessas diferentes etapas, eu e o VP de dados tentamos nos sentar e mapeá-las para cargas de trabalho específicas de agents. A segunda versão desse agent de ciência de dados, chamado D0 — vou me referir a ele como D0 daqui em diante —, é assim: você faz uma pergunta. Temos um agent de consulta que encaminha uma consulta ao agent de planejamento, que então aciona um agent de execução, e assim por diante.

04:59 Se você encadear todos eles, obtém algo assim, em que cada agent tem um system prompt dedicado, focado na função que desempenha, com ferramentas limitadas exatamente a essa função. Por exemplo, aqui você pode ver que, no primeiro caso, o agent de planejamento tem uma ferramenta para ler entidades em YAML e uma ferramenta de busca de esquemas. E, portanto, ele só usará esses

05:32 recursos até ter uma resposta para encaminhar ao agent de planejamento, depois ao agent de SQL e, por fim, ao de relatórios. Isso estava melhorando. Sabe, conseguimos deixar de copiar e colar SQL e depois voltar para apresentar os resultados. Agora, o sistema estava realmente fazendo o ciclo completo, da pergunta à resposta. Mas começamos a encontrar alguns obstáculos com essa arquitetura. E, por volta dessa época, chegamos à conclusão de que, na verdade, o que você precisa é de um único agent com todo o mega contexto dentro dele, que gerencie a própria memória. Sabe, foi nessa época que percebemos que você quer que o agent consiga olhar para o que fez, refletir e descobrir quais etapas o levaram até ali. No modelo anterior, talvez você tenha notado que a única coisa que o próximo agent recebe é um resumo e um pequeno trecho do que foi feito antes. Já com essa abordagem, dá para imaginar um mega agent que gerencia internamente o próprio estado. Em alguns momentos, ele está planejando; em outros, construindo; em outros, executando; e, em outros, apresentando os resultados. E era mais ou menos assim que isso se parecia. Você tem uma grande

06:06 chamada de IA, talvez com um máximo de 100 etapas, e dá a ela a capacidade de gerenciar o próprio estado de acordo com o ponto em que está na jornada de execução. Então, você pode ver ferramentas parecidas e uma estrutura semelhante, mas o melhor disso é que, se ele encontrasse um erro durante a execução ou uma junção, poderia voltar e explorar mais, ou ler mais e descobrir o que estava fazendo errado. Nesse ponto, ele era muito bom. Estávamos bem confiantes no sistema em si e o disponibilizamos para alguns membros de confiança da Vercel.

06:38 Sabe, essa é uma ferramenta muito poderosa, e não queríamos colocá-la nas mãos de pessoas erradas ou de pessoas que a usariam em cargas de trabalho muito críticas. Então, demos acesso a algumas pessoas, e a reação imediata foi que era péssima. Sabe, achávamos que estávamos arrasando. Achávamos que isso estava acertando 30% das nossas evals, mas não poderíamos ter previsto algumas das perguntas que estavam sendo feitas. E dedicar mais tempo a mapear manualmente alguns desses cenários não parecia uma forma muito escalável de fazer isso. Aí, o Claude Code e o Opus 4.5 foram lançados. Bem, mais precisamente, o Opus 4.5 foi lançado

07:08 Sabe, esta é uma ferramenta muito poderosa, e não queríamos realmente colocá-la nas mãos das pessoas erradas ou de pessoas que a usariam em cargas de trabalho muito críticas. Então, ela chegou às mãos de algumas pessoas, e a reação imediata foi: era horrível. Sabe, achávamos que estávamos mandando bem. Achávamos que estávamos, sabe, acertando 30% dos nossos evals, mas não tínhamos como prever algumas das perguntas que estavam sendo feitas. E dedicar mais tempo a mapear manualmente alguns desses cenários não parecia uma forma muito escalável de fazer isso. Aí saíram claude code e opus 4.5. Bem, mais precisamente, saiu Opus 4.5

07:41 e isso, em conjunto com o Claude Code, que é tão poderoso. Sabe, eles meio que desbloquearam o conceito de um agent de sistema de arquivos, e nós, de fora, ficamos tipo: “Nossa, Claude Code e Opus 4.5 são basicamente AGI em comparação com o que tínhamos antes.” Sabe, ele respondia à maioria das nossas perguntas sem nem sequer hesitar, em comparação com o agent que tínhamos desenvolvido à mão. E, quando tentamos dar um passo atrás e pensar no que estávamos fazendo de errado e por que aquilo era muito melhor, percebemos que o grande avanço era simplesmente ser um sistema de arquivos

08:13 . Sabe, ele tinha um conjunto bem mínimo de ferramentas: listar arquivos, ler arquivos e executar bash. E adicionamos mais algumas para o nosso caso de uso de agent de dados. Mas o mais importante era que ele conseguia usar as ferramentas com as quais agents são bem treinados e explorar e escrever o que fosse necessário. Sabe, não estávamos dando ao Claude Code — ele não estava dando — um conjunto muito prescritivo de ferramentas. Era como se simplesmente o deixássemos à vontade para explorar e apresentar comportamentos emergentes. Então, com isso, aprendemos que dá mesmo para usar apenas um sistema de arquivos. Sabe,

08:45 vimos os aprendizados do Claude Code e o quanto ele era poderoso, já que simplesmente executava tudo localmente. E tentamos recriá-lo de uma forma bem parecida com o Claude Code. Sabe, agora ele seria executado em um sandbox. Esse sandbox carregaria toda a camada semântica. O agent poderia usar bash, ler arquivos, gravar arquivos e explorar tudo para descobrir o que precisa, e nós só acrescentaríamos algumas ferramentas para garantir que ele pudesse fazer tudo o que é específico da Vercel. E esse foi, na verdade, o maior avanço de todos. Sabe, o salto de um agent único para o SDK do Claude Code e, depois,

09:19 do SDK do Claude Code para agents de sistema de arquivos em geral, com fine-tuning ou criados especificamente para o nosso caso de uso, foi um salto incrível. Nesse momento, começávamos a nos preparar para disponibilizá-lo a mais pessoas na Vercel. E, nesse ponto, a pontuação nas evals praticamente dobrou. Escrevi isto — é basicamente assim que funciona. É bem simples. Basta dar a ele uma ferramenta bash. Temos um helper bem legal chamado bash tool no npm, que você conecta a um sandbox; também pode anexar arquivos ao sandbox para que ele os leia, grave e execute. E, depois dessa descoberta e de ver que estávamos acertando tantas perguntas que antes não conseguíamos responder, eu

09:52 escrevi esta postagem de blog incrível. Ela está no ar hoje. E, na semana em que a escrevi, foi responsável por 70% do tráfego de vercel.com. Então, sabe, é uma postagem incrível. Depois disso, o próximo passo lógico era descobrir quais eram os casos de uso mais comuns. A essa altura, já tínhamos dado certa liberdade a todos na Vercel, e recebíamos milhares de consultas por dia de pessoas querendo tudo, desde métricas de clientes e métricas de vendas até números

10:25 de métricas e downloads do npm. E descobrimos que muitas dessas consultas tinham, na verdade, o mesmo formato. Sabe, há um número limitado de maneiras de fazer uma agregação, de consultar um produto ou de obter informações de faturamento. Então, temos um job recorrente que pega as consultas mais recentes e tenta destilá-las em uma skill. Agora, temos cerca de 100 skills, que fazem de tudo, desde agregações até consultas a dados específicos sobre determinadas pessoas. E descobrimos que isso é muito eficaz porque, se você pensar em cada nova execução de um agent, ela meio que começa do zero. Sabe,

10:56 não há contexto pré-estabelecido, além da camada semântica e do system prompt. Mas, com uma skill, ele já começa com bastante conhecimento contextual que, de outra forma, já teria sido obtido antes. E é mais ou menos assim que funciona. É muito parecido com o exemplo anterior, mas a inclusão de uma pasta de skills é realmente poderosa. Também criamos uma ferramenta na Vercel chamada skills.sh. É a forma mais popular de encontrar skills para agents e executá-las por conta própria. E estou dizendo tudo isso porque esse é um caminho que muitos de vocês talvez percorram em algum momento: começar

11:29 com algo simples, adicionar complexidade aos poucos e, por fim, chegar a um sistema que possa ser colocado em produção. Estou contando isso porque, em cada etapa da criação desse agent, alguém na Vercel se interessava por agents e tentava fazer um fork do meu agent D0 e criar o próprio. E, em cada etapa, acabávamos encontrando uma forma melhor de fazer algo que antes não era conhecida. E ficávamos pensando: e se hoje as pessoas pudessem começar pela descoberta mais recente e não precisassem começar com um prompt simples nem

12:00 reinventar os melhores princípios a partir dos primeiros princípios? Então, pensamos: e se criássemos o Next.js dos agents? Para quem não conhece, o Next.js é um framework web popular criado pela Vercel, que inventou essa ideia de infraestrutura definida por framework e sistema de arquivos. Você não precisa se preocupar com onde as coisas ficam. Só precisa gravar os arquivos seguindo as convenções certas, e o framework determina automaticamente onde eles devem ficar. Suas páginas vão para a CDN. Suas funções serverless vão para lá. O cache fica

12:30 no meio. E pensamos: criar agents deveria ser assim tão simples. Você deveria precisar apenas criar uma pasta de skills, uma pasta de tools e uma pasta de channels, e conseguir declarar tudo isso com facilidade. O framework deveria saber exatamente como transformar isso em um agent. Por isso, há duas semanas lançamos o Eve. Eve é um framework de agents, como o Next.js dos agents, que facilita muito começar com um template de exemplo e chegar a um agent totalmente pronto, ao qual você pode adicionar seus próprios conhecimentos, suas próprias ferramentas e até integrar os channels

13:01 com os quais já está familiarizado. É mais ou menos assim que achamos que um agent deve ser. Sabe, um agent tem um runtime e tem channels. Nesse runtime, você vai precisar de durabilidade. Vai querer executar coisas em um ambiente isolado. Vai querer chamar diferentes modelos. E vai querer ter conexões. Criamos isso pensando em open source. Sabe, criamos o Eve para que você possa conectar seus próprios adaptadores open source para Postgres, a API de responses da OpenAI, Docker e outros conectores. Mas também facilitamos muito o deploy na Vercel. A única coisa que você vê aqui

13:32 de diferente é que tudo aqui usa um produto da Vercel que desenvolvemos ao longo dos anos para facilitar a criação dessas experiências: Vercel Workflows para durabilidade, sandbox para execução segura e Vercel Connect, algo que acabamos de lançar para facilitar a geração de tokens ODC de curta duração para conexões. E, enquanto criávamos o Eve, reescrevemos nele o agent D0. Por trás dos panos, a estrutura era complicada, mas isso não aparecia no código. É mais ou menos assim que o sistema de arquivos fica. É bem simples. Você tem

14:02 um conjunto de instruções de sistema, algumas skills e algumas tools, e é muito fácil compor tudo isso em um agent de verdade, além de ser muito fácil iterar. Na verdade, disponibilizamos isso para alguns clientes beta antes do lançamento oficial, há duas semanas, no nosso evento em Londres. Uma dessas empresas, que é uma parceira próxima, é a Aura. Eles reconstruíram o agent deles, que é meio que um mini Claude, para testar os serviços das pessoas. Ele acessa sites, instala os serviços e tenta usá-los. E eles tiveram muito sucesso ao criar

14:33 o próprio agent do zero usando o Eve, em comparação com o uso de uma solução pronta, como o Claude Code. São necessárias menos etapas, os resultados são melhores e os insights também. E, quando você faz o deploy do Eve na Vercel, recebe observabilidade pronta para usar. Aqui dá para ver todas as execuções do agent, todas as chamadas de ferramentas, cada etapa que ele realiza e também algumas estimativas de custo e possíveis otimizações. Você pode começar hoje mesmo em eve.dev. Basta clonar e

15:04 começar com um template, fazer deploy com facilidade e hospedar por conta própria, se precisar. E o motivo de eu trazer isso à tona é que espero que haja cada vez mais agents voltados a casos de uso específicos de negócios. Sabe, antes de criarmos o Ezero, testamos bastante, na prática, muitas startups bem financiadas do setor que estavam desenvolvendo agents verticais dedicados a acessar sua instância do Snowflake e permitir que o agent executasse consultas no Snowflake nela. Mas descobrimos que o que realmente torna esse agent bom é ele ter muito conhecimento muito

15:36 específico da empresa. Sabe, a Vercel é uma empresa focada na web. Temos muitos clientes com sites e propriedades na web. Isso se aprofunda bastante em questões como quando consultar cada coisa e quais elementos estão vinculados a quais outros. E muitos desses agents prontos para uso são ótimos. São bons para experimentar, mas acho que, se você realmente quiser tirar o máximo proveito, deveria tentar criar seu próprio agent e acrescentar o máximo possível de conhecimento específico da empresa. Hoje, sabe, temos aproximadamente 20 agents com um PMF razoável na Vercel

16:06 que vão desde retrospectivas de marketing para descobrir com quem entrar em contato até a primeira revisão de um contrato com alterações, quando a equipe jurídica recebe uma nova negociação, sem falar no meu agent de ciência de dados, que ajuda com consultas de dados. Isso mostra que sempre fomos uma empresa muito repleta de agents. Sabe, tudo isso está nos economizando muito tempo. A equipe de dados nunca foi tão produtiva. Agora tem mais tempo para melhorar o desempenho do Snowflake, adicionar novas fontes de dados que

16:40 estavam faltando e preencher lacunas que antes não tinha tempo de preencher porque estava ocupada demais escrevendo consultas. E acho que nunca foi tão fácil para empresas grandes, pequenas ou médias automatizarem algumas das coisas que não querem fazer ou algumas das coisas a que estão dedicando tempo demais. Sabe, acho que muitas tarefas de RH, finanças e vendas podem ser parcialmente automatizadas com agents. E acho que a Vercel é a melhor maneira de criar esses agents hoje. Estas são minhas redes sociais. Obrigado a todos

17:11 por virem e ouvirem. Eu sou Andrew e vou ficar por aqui, caso queiram conversar lá fora. >> [música]

Transcrição original

[00:12] 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

[00:43] 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

[01:16] 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

[01:52] 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

[02:24] 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,

[02:56] 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

[03:28] 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

[03:59] 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

[04:29] 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

[04:59] 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

[05:32] 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

[06:06] 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

[06:38] 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.

[07:08] 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

[07:41] 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

[08:13] 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,

[08:45] 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

[09:19] 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

[09:52] 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

[10:25] 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,

[10:56] 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

[11:29] 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

[12:00] 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

[12:30] 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

[13:01] 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

[13:32] 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

[14:02] 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

[14:33] 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

[15:04] 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

[15:36] 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

[16:06] 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

[16:40] 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

[17:11] for coming and listening. I’m Andrew and I’ll be around if you want to chat outside. >> [music]