Por dentro do ecossistema MCP da Weaviate | Webinar

Autoria: Weaviate vector database · 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: Inside Weaviate’s MCP Ecosystem | Webinar · Canal: Weaviate vector database · 54:44 · Assistir no YouTube

Tópicos: Agentes de IA, Dados, bancos de dados e embeddings, Engenharia de software com IA, RAG, busca e recuperação de informação

Resumo

O webinar apresenta o ecossistema MCP da Weaviate, incluindo o servidor integrado ao banco de dados e o servidor MCP do Query Agent. Os palestrantes demonstram como conectar assistentes aos dados, consultar coleções e inserir objetos, além de explicar recursos de busca, RAG e geração estruturada. Alex Ledbetter conta como usou vibe coding e Weaviate para criar uma corretora de seguros comerciais com atendimento apoiado por IA. A sessão termina com perguntas sobre escolhas técnicas, disponibilidade dos servidores e a stack usada no desenvolvimento.

Pontos-chave

O servidor MCP do banco de dados é integrado à Weaviate e oferece ferramentas para inspecionar configurações e tenants, fazer buscas híbridas e inserir ou atualizar objetos.
O acesso ao servidor usa uma chave de API e as permissões do cluster; no modo self-hosted, a escrita fica desativada por padrão.
O Query Agent traduz perguntas em linguagem natural em consultas, combina buscas e filtros e oferece recursos de RAG com respostas fundamentadas nos dados.
Entre as novidades apresentadas estão saídas estruturadas, geração de imagens aumentada por recuperação, níveis de esforço de busca e um modo de pesquisa em prévia de produto.
O MCP facilita a integração com clientes e frameworks, enquanto os clientes Python e TypeScript oferecem mais controle e personalização.
A corretora de Alex usa Weaviate para organizar documentos de seguros, extrair informações e oferecer atendimento em vários canais.
A arquitetura da corretora combina dados estruturados e não estruturados, imagens de páginas e diferentes agentes para classificar documentos e responder a solicitações.
Na conversa sobre a stack, Alex destaca Weaviate, AWS, Supabase e CLI, e afirma que usaria Weaviate para dados estruturados e não estruturados se recomeçasse.

Capítulos

Início	Capítulo	Resumo
00:03	Abertura e agenda do webinar	Andy Ellicott apresenta os palestrantes, a agenda e o formato de perguntas e respostas.
01:36	Visão geral da Weaviate	A apresentação resume o banco de dados vetorial e os componentes da plataforma.
03:10	Introdução ao ecossistema MCP	Yevon explica o protocolo MCP e apresenta os servidores disponíveis no ecossistema Weaviate.
06:15	Servidor MCP integrado ao banco de dados	A demonstração explica autenticação, permissões e as quatro ferramentas disponíveis no servidor.
08:50	Demonstração de consultas e inserção de dados	O assistente conecta-se a um cluster, consulta produtos e adiciona um item à coleção.
13:43	Recursos do Query Agent	Connor apresenta os recursos de compreensão de esquema, criação de consultas e geração fundamentada.
18:22	Novidades e pesquisa aprofundada	A apresentação aborda saídas estruturadas, geração de imagens aumentada por recuperação, níveis de esforço e pesquisa em prévia.
20:59	Integração do Query Agent por MCP	Connor mostra como conectar o servidor a clientes, aplicações e frameworks, e compara MCP com os clientes nativos.
25:08	A história de Alex e a criação da corretora	Alex conta sua trajetória, o início do desenvolvimento com IA e a decisão de construir a plataforma por conta própria.
28:15	Documentos, memória e atendimento em seguros	Alex demonstra como a plataforma organiza documentos, extrai dados e oferece atendimento em diferentes canais.
35:04	Ferramentas para autoatendimento dos clientes	A corretora usa ferramentas MCP para automatizar solicitações, documentos e operações de seguros.
40:16	Perguntas sobre a escolha da Weaviate	Andy e Alex discutem fatores como facilidade de uso, flexibilidade, escalabilidade e suporte técnico.
46:25	Disponibilidade dos servidores e avaliação de respostas	Os palestrantes esclarecem a disponibilidade dos servidores MCP e como o Query Agent avalia respostas fundamentadas.
48:58	Stack de desenvolvimento e encerramento	Alex comenta suas ferramentas e a arquitetura multiagente, e Andy encerra o webinar com recursos adicionais.

Citações

Não há pacote, contêiner extra nem nada para instalar. — 06:15

O assistente descobriu o cluster por conta própria. Pesquisou, consultou o esquema do banco de dados e buscou alguns objetos para entender o contexto. — 13:11

Com o servidor MCP, você abre mão de um pouco de controle e personalização, mas a integração fica muito fácil. — 24:37

Se eu fosse fazer de novo, usaria Weaviate para dados estruturados e não estruturados. — 53:43

Conceitos e entidades

Weaviate (empresa): Empresa e banco de dados vetorial open source apresentados como plataforma para aplicações de IA.
MCP (conceito): Protocolo aberto que permite a assistentes e ferramentas de IA acessar dados e chamar ferramentas externas.
Weaviate Database MCP server (ferramenta): Servidor integrado ao banco de dados Weaviate que oferece ferramentas para consultar e modificar dados do cluster.
Query Agent (ferramenta): Agente da Weaviate que interpreta perguntas, constrói consultas e aplica recursos de recuperação e geração fundamentada.
Query Agent MCP server (ferramenta): Servidor MCP que disponibiliza os modos do Query Agent para clientes e aplicações compatíveis.
RAG (conceito): Abordagem que fundamenta as respostas geradas por IA em informações recuperadas de dados específicos.
vibe coding (conceito): Forma de desenvolver software com assistência de IA, usada por Alex para criar sua plataforma.
Claude Code (ferramenta): Cliente mencionado para conectar-se aos servidores MCP e auxiliar no desenvolvimento.
Cursor (ferramenta): Ferramenta de desenvolvimento que Alex usou antes de migrar para Claude Code.
Pydantic AI (ferramenta): Framework citado como opção para criar agentes que utilizam ferramentas MCP.
LangChain (ferramenta): Framework apresentado como exemplo de integração com o Query Agent MCP server.
Alex Ledbetter (pessoa): Fundador e CEO da Delegance Brokerage, que relata a criação da corretora com assistência de IA.
Delegance Brokerage (empresa): Corretora de seguros comerciais criada por Alex Ledbetter com uma plataforma apoiada por IA.
AWS (empresa): Plataforma de nuvem citada por Alex como parte da infraestrutura usada no desenvolvimento.
Supabase (empresa): Plataforma citada por Alex entre os componentes de sua stack de desenvolvimento.

Tradução completa (pt-BR)

00:03 Certo. Olá a todos e bem-vindos ao webinar de hoje, “Por dentro do ecossistema MCP da Weaviate”. Sou Andy Ellicott, e meus coapresentadores de hoje são Ivan e Connor, da equipe de engenharia da Weaviate. Também temos Alex Ledbetter, CEO e fundador da Deligence brokerage, que vai falar sobre sua experiência usando vibe coding com a Weaviate. Nossa agenda de hoje começa com uma breve introdução e uma visão geral da Weaviate, caso você ainda não a conheça, e, em seguida,

00:35 Ivan vai falar sobre o novo servidor MCP para o banco de dados Weaviate, seguido por Connor, que vai explicar o servidor MCP para o agente de consulta da Weaviate. Para encerrar, Alex vai falar sobre como, acredito que praticamente sozinho e sem muita experiência em ciência da computação, usou vibe coding para criar uma corretora de seguros comerciais em menos de um ano. E, pelo que sei, ontem

01:06 ele anunciou sua rodada de financiamento pré-seed. Então, está começando muito bem, e a história dele é realmente interessante e muito relevante para todos aqui que vieram a este evento na esperança de aprender mais sobre programação assistida por IA e operações com a Weaviate. Vamos encerrar com perguntas e respostas. Se tiver alguma pergunta em qualquer momento durante o webinar, use o botão de perguntas e respostas na tela do Zoom, e vamos respondê-las no final. Vamos responder a tantas quanto o tempo

01:36 permitir. E, como uma das perguntas mais comuns que recebemos é “A gravação será compartilhada?”, sim, será. O evento de hoje está sendo gravado, e vamos compartilhar uma gravação em vídeo depois do evento, caso você queira rever algum trecho ou compartilhá-lo com outras pessoas. Certo, vamos começar com uma breve introdução à Weaviate para quem ainda não a conhece. A Weaviate é um banco de dados vetorial open source. Ele foi criado especificamente para casos de uso de IA, como busca semântica, IA generativa, RAG, inference de IA, IA agêntica e muitos outros.

02:08 Ele torna a criação de aplicações de IA excepcionalmente fácil, porque foi desenvolvido especificamente para indexar e pesquisar dados vetoriais com muita, muita rapidez para esse tipo de aplicação. Também é bastante capaz de escalar e ter desempenho rápido o suficiente para dar suporte a iniciativas de IA realmente grandes, como acontece com clientes da Weaviate, como Booking e Cisco, entre muitos outros. A Weaviate faz parte de uma plataforma que inclui

02:38 alguns outros componentes, incluindo o agente de consulta, sobre o qual Connor vai falar hoje. O agente de consulta facilita consultas em linguagem natural aos seus dados. Há também o Weaviate Embeddings, um recurso que permite conectar modelos de IA ao banco de dados para facilitar e simplificar as arquiteturas de aplicações, possibilitando a geração de dados vetoriais dentro do próprio banco de dados. E, por fim, o Ingram, um produto mais recente

03:10 que dá a você um impulso inicial para usar a Weaviate como memória de IA, em personalização e em outras aplicações de IA. Certo. Essa foi a Weaviate em um minuto. E, sem mais delongas, vou passar a palavra a Yevon, que vai entrar em detalhes sobre o novo servidor MCP para o banco de dados Weaviate. >> Obrigado pela introdução. Vamos direto ao assunto. Olá a todos. Sou Yevon. Trabalho com a experiência de desenvolvedores

03:40 aqui na Weaviate e ajudo a desenvolver o servidor MCP do banco de dados. Hoje, vou dar uma breve visão geral do ecossistema MCP que usamos na Weaviate, mostrar o servidor integrado ao banco de dados e passar algum tempo em uma demonstração ao vivo com a Weaviate Cloud, mostrando como usar as ferramentas MCP. Primeiro, o mapa do ecossistema e uma introdução bem breve ao MCP para quem ainda não conhece. MCP, o Model Context Protocol, é um padrão aberto que permite que assistentes de IA e ferramentas leiam dados e chamem outras ferramentas fora do próprio sistema.

04:11 Ele começou na Anthropic há cerca de dois anos e agora está sob a Linux Foundation. Ferramentas como Claude, ChatGPT e Cursor usam esse protocolo. Basicamente, é um protocolo para que ferramentas com IA se comuniquem diretamente com vários servidores, aplicações e, essencialmente, qualquer coisa que você possa imaginar. No topo do slide, você pode ver alguns dos clientes que talvez já esteja

04:42 usando, e abaixo estão os servidores do ecossistema da Weaviate. Por exemplo, à esquerda está o servidor MCP da documentação da Weaviate. Ele é hospedado e operado pela Kappa AI e disponibiliza diretamente a documentação da Weaviate para o seu assistente. Por exemplo, se você estiver usando um assistente de IA para desenvolver código com a Weaviate e tiver dúvidas sobre a API ou sobre alguns valores de configuração na Weaviate, em vez de fazer uma busca na web, você pode perguntar diretamente ao servidor MCP da documentação, e provavelmente obterá mais precisão do que tentando buscar os dados por conta própria.

05:14 Em seguida, temos o servidor MCP do banco de dados Weaviate. Ele é integrado diretamente ao próprio banco de dados Weaviate e dá ao seu assistente acesso direto ao seu cluster. Assim, você pode inspecionar o esquema, pesquisar seus dados e gravar objetos nele. Vou explicar esse servidor com mais detalhes nos próximos slides e na demonstração. Ao lado dele está o MCP do agente de consulta. Em vez de consultar o banco de dados diretamente usando o servidor MCP do banco de dados, você usa um agente ou assistente dedicado com IA, que já sabe como transformar suas perguntas nas consultas certas e com muito mais precisão do que sua ferramenta de IA conseguiria. Connor vai falar mais sobre isso depois.

05:45 E, claro, você também pode criar servidores MCP personalizados se tiver um caso de uso muito específico que não seja atendido por nenhum dos servidores mencionados.

06:15 Agora, vamos falar sobre o servidor MCP do banco de dados Weaviate. Você pode ver a arquitetura do nosso servidor MCP integrado. O que significa “integrado”? Não há pacote, contêiner extra nem nada para instalar. Quando você executa a Weaviate, o servidor MCP já está em execução dentro dela e é disponibilizado em /v1/mcp, na mesma porta da API REST. Seguindo a seta da esquerda para a direita, você pode ver que seu cliente, por exemplo,

06:45 Claude Code, VS Code ou um agent, se conecta por HTTP transmitido em fluxo e usa uma chave de API normal da Weaviate para se autenticar no cluster. Cada chamada passa pela mesma autenticação e pelo mesmo RBAC que o restante da API. Cada ferramenta também é mapeada para permissões específicas. Por exemplo, se você der ao seu assistente uma chave somente de leitura, ele terá apenas acesso de leitura ao seu cluster. Assim, a

07:18 ferramenta de IA não poderá realizar operações destrutivas. Atrás da barreira, você pode ver as quatro ferramentas disponíveis atualmente. A ferramenta de escrita está marcada com um cadeado porque, por padrão, na versão da Weaviate auto-hospedada, o acesso de escrita fica desativado. Você precisa ativá-lo. Na Weaviate Cloud, que vou mostrar na demonstração, o servidor MCP vem ativado por padrão, assim como o acesso de escrita, mas você pode

07:48 desativá-lo. Você também pode conceder permissões granulares a uma chave de API, para que o MCP tenha acesso apenas a certos dados restritos. As quatro ferramentas disponíveis são: a ferramenta para obter a configuração de uma coleção, que permite ao seu assistente saber quais dados estão no cluster, como as propriedades, qual vectorizer está sendo usado e se o multi-tenancy está ativado; e a ferramenta para listar tenants, usada para inspecionar coleções com multi-tenancy,

08:20 e ver quais tenants fazem parte delas. A ferramenta de consulta híbrida combina busca vetorial e por palavras-chave, por isso é a principal ferramenta de busca usada para recuperar dados da Weaviate. A ferramenta upsert é a principal ferramenta de escrita, que você pode usar para inserir novos dados ou substituir dados existentes como uma atualização. À direita, você também pode ver as permissões de RBAC associadas às ferramentas, para conceder acesso granular ao que um agent pode usar.

08:50 Agora, vamos mostrar tudo isso em ação. Primeiro, precisamos de um cluster da Weaviate Cloud. Já criei um, como você pode ver no painel principal. Este é o endpoint REST que vamos usar para nos conectar ao MCP. Você também pode clicar no botão “Como conectar” e, aqui, na aba MCP, encontrará um comando que pode executar diretamente na ferramenta que está usando. Este é para o Claude Code. Há também outras opções

09:23 disponível. Já conectei o meu localmente, então você não precisa ver a chave de API. Vamos conferir. Primeiro, vamos verificar se a conexão foi estabelecida. Vou fazer isso com o comando MCP, e aqui posso ver que estamos conectados à V8 cloud. Vamos conferir também. Esta é a URL REST do cluster que mostrei antes. E aqui também podemos ver as ferramentas disponíveis. Isso não é

09:55 realmente importante para você como usuário. É isso que o agent vai usar no fim das contas. Por exemplo, esta é a descrição e estes são os parâmetros que o agent verá e poderá configurar por conta própria. Então, agora vamos fazer uma consulta de verdade. Primeiro, vamos perguntar o que há no cluster V8 cloud. E, se tudo der certo,

10:27 como sempre acontece com demonstrações ao vivo desse tipo, ele vai usar a ferramenta correta. Sim, é a ferramenta V8 collection get config, para que possa verificar o schema do cluster. E agora também vai executar a ferramenta V8 query hybrid para conferir alguns dos objetos armazenados na coleção de roupas. Também encontrou uma segunda coleção, uma coleção de marcas. Ele também quer consultar essa coleção. Vamos deixar.

11:00 E, em poucos segundos, ele deve entender os dados que recuperou do cluster. E aqui está. É um conjunto de dados de e-commerce com duas coleções: uma de roupas, essencialmente um catálogo de produtos com diferentes peças de roupa, e marcas associadas a essas peças. Então, agora vamos fazer, por exemplo, uma consulta realista que alguém usaria em uma aplicação web de e-commerce. Encontre um vestido de verão para um casamento

11:35 por menos de 200 dólares. E vamos ver como ele vai interpretar esse pedido em linguagem simples e transformá-lo em uma consulta. Aqui vemos que está pesquisando na coleção de roupas. A consulta é “vestido elegante de verão para uma convidada de casamento”. Está limitando a oito resultados. Aqui, está aplicando filtros específicos porque eu disse vestido. Está pesquisando na categoria de vestidos. O preço precisa ser inferior a 200. E

12:06 como não especifiquei o que retornar, ele vai retornar todas as propriedades. Certo, vamos executar. Legal, funcionou. Vou mostrar outra consulta. Vamos, por exemplo, adicionar um produto. Então, adicione um novo produto à coleção de roupas com mais alguns detalhes.

12:39 E, mais uma vez, ele vai construir a chamada da ferramenta. Está usando a ferramenta objects upsert. À primeira vista, vejo que preencheu todos os campos corretamente. Agora, vamos executar. Quero saber se ele vai fazer uma busca híbrida só para verificar se funcionou. E sim, vai fazer isso. Vamos ver se vai encontrá-lo.

13:11 E suponho que tenha funcionado. Sim, adicionou o Harbor Cashmere Crewneck à coleção de roupas. Também criou a marca. Então, aqui vocês podem ver que tudo o que tentamos em linguagem simples deu certo até agora. Esse é o ciclo completo. O assistente descobriu o cluster por conta própria. Pesquisou nele. Consultou o schema do banco de dados, buscou alguns objetos para entender o contexto. Essas quatro ferramentas estão atualmente

13:43 disponíveis, mas vocês podem esperar que ampliemos o MCP com ferramentas adicionais no futuro também. É isso da minha parte. >> Obrigado, Yevhen. Em seguida, se pudermos, vamos passar para Connor, que vai detalhar o servidor MCP do Weaviate query agent. >> Ótimo. Muito obrigado pela introdução, Andy, Yevhen e Alex, e à Laura por organizar tudo. Obrigado a todos por estarem aqui. Estou muito animado para

14:13 falar sobre o Weaviate query agent. Vou falar sobre algumas novidades e, em seguida, focar no nosso servidor MCP, uma das adições mais recentes ao Weaviate query agent. Um breve destaque do que há de novo: saídas estruturadas, geração de imagens com RAG e o modo de pesquisa do effort aqui no nosso servidor MCP do query agent. Há muitas coisas empolgantes. Foi muito divertido trabalhar nisso. Estou muito animado com isso. Antes de falar sobre as novidades, vamos fazer uma breve contextualização para quem ainda não conhece o query agent. RAG trata de fundamentar as gerações de sistemas de IA nos seus dados específicos.

14:45 Imagine fazer uma pergunta como: “Quais jaquetas impermeáveis com preço abaixo de 200 dólares estão em estoque?” Essa é uma pergunta completamente sem sentido para fazer a um LLM. A resposta depende inteiramente de estar fundamentada nos seus dados. Há todo tipo de exemplo envolvendo dados privados e a combinação dos seus dados internos com conhecimento público. Todas essas situações em que o RAG complementa as gerações e permite coisas como verificar alucinações, garantindo que as respostas produzidas pelos sistemas sejam realmente respaldadas pelos dados no seu banco de dados Weaviate.

15:16 O query agent foi desenvolvido para RAG com Weaviate. É um agent projetado em conjunto com o banco de dados. E há todo tipo de maneira interessante como isso se manifesta. Algumas das principais áreas são a compreensão do schema, a criação de consultas e, depois, as camadas de IA que integramos a essas aplicações, como geração arbitrária, chatbots, busca ou pesquisa, que incluem reordenação, tratamento de contextos longos, geração fundamentada e verificação de alucinações. Vou apresentar rapidamente alguns dos principais recursos do query agent.

15:47 A compreensão do schema talvez seja o melhor exemplo desse projeto conjunto, além da parte que funciona como texto para SQL. Analisamos os schemas das coleções e sabemos como interpretar o que é retornado pelas meta APIs do Weaviate para transformá-lo em um prompt e também em uma saída estruturada para escrever consultas do Weaviate. Temos o amostrador de dados, que usamos para inspecionar parte dos dados. Depois, temos o inspetor de filtros, que analisa a distribuição dos valores desses filtros. Por exemplo, adoro este caso de jogos de Pokémon, em que você pode ter uma propriedade de cor; só pela cor, o LLM

16:18 não teria como saber que os valores específicos que ela assume são ruby, sapphire e emerald. Esse é um exemplo de como podemos projetar o agent em conjunto para fornecer informações sobre os dados no seu banco de dados e viabilizar essas aplicações de IA. Depois, traduzir as perguntas dos usuários em consultas do Weaviate significa converter perguntas em linguagem natural em consultas estruturadas do Weaviate, conseguir escrever consultas de busca, usar filtros para recuperar objetos, combinar buscas e filtros e aplicar agregações aos seus dados. Por exemplo, se você tiver uma propriedade numérica

16:48 de preço, poderá calcular o preço médio no Weaviate, assim como faria em um banco de dados relacional. O Weaviate também oferece um suporte muito forte a dados estruturados. Além disso, temos algumas camadas de IA, como reordenação e tratamento de contextos longos. Por exemplo, alguns dos objetos retornados pelo Weaviate podem ser enormes, ou você pode estar recuperando imagens do banco de dados. O query agent consegue ler suas imagens, sejam recursos de marca, gráficos ou páginas de PDF. Também consegue fazer isso no query

17:18 agent, além de lidar com conversas longas. E uma parte enorme, simplesmente essencial, dessas aplicações de IA é a geração fundamentada: garantir que cada resposta seja verificada com base nos seus dados, para que você não precise se preocupar com alucinações com o query agent. Com essa base, oferecemos quatro modos, quatro aplicações que aproveitam essa funcionalidade: o modo de perguntas, o modo de busca, o modo de sugestão de consultas e o modo de pesquisa. São maneiras diferentes de usar o query agent. O modo de perguntas é meio que um modo bem geral, como a API de respostas dos SDKs de LLM da

17:50 OpenAI, em que você pode fazer muitas coisas. O modo de busca consiste em revelar a camada de busca que fica por baixo e oferecê-la nativamente para uso em buscas. A sugestão de consultas é uma ferramenta auxiliar para criar chatbots. É algo útil para o desenvolvedor e para a experiência de quem usa o chatbot: sugerir consultas que seus dados podem responder, além de sugerir perguntas de acompanhamento ao criar chatbots e lidar com conversas longas. E o modo de pesquisa — estou muito animado com o modo de pesquisa. Acho que é uma tecnologia incrível.

18:22 Então, criamos o agente de consulta pensando na personalização. Temos muitos recursos para ajudar você a ajustá-lo às suas necessidades. Você pode importar um system prompt personalizado. Pode definir os níveis de esforço. Também temos recursos específicos para quem quer ter um controle bem granular sobre a filtragem que o agente de consulta vai usar ao pesquisar os dados no Weaviate. Muito bem, agora vamos falar sobre algumas das novidades em que temos trabalhado. Acho que todas essas coisas são extremamente legais. Para começar, vamos falar de saídas estruturadas. Saídas estruturadas são uma maneira muito legal de, quando um LLM gera

18:54 qualquer coisa, especificar o tipo das saídas que ele vai produzir. Digamos que ele vá escolher uma jaqueta e que ela tenha um nome, um preço e uma indicação de ser ou não impermeável. Agora adicionamos suporte a saídas estruturadas no modo de consulta. E uma parte incrivelmente legal disso é como adicionamos a geração de imagens aumentada por recuperação. Assim, uma dessas saídas estruturadas pode ser uma imagem. Este é o exemplo mais popular que usamos internamente: criar um anúncio do nosso mascote vestindo o nosso suéter mais vendido, e você recebe este

19:25 canguru incrível usando um cardigã laranja. Então, o agente de consulta consegue analisar seus dados para descobrir quem é o nosso mascote. Pode encontrar imagens desse canguru e, depois, pesquisar nas suas imagens para descobrir qual é o nosso suéter mais vendido. O nosso suéter mais vendido demonstra essa capacidade de ordenar os objetos pelo número de vendas para recuperar esse tipo de informação, combinando isso com a geração de imagens aumentada por recuperação. Estou muito animado com o potencial disso. Também temos os níveis de esforço, que chegaram primeiro ao modo de busca. Para

19:57 dar uma ideia do que isso significa, fizemos um benchmark em um benchmark de busca, no qual basicamente se avalia a precisão dos resultados de busca para uma coleção de, digamos, neste caso específico, cerca de 500 mil documentos. O documento correto, de referência ou anotado por humanos, está entre os 1, 5 ou 20 primeiros resultados? A busca híbrida, por si só, produz estes números. Usando a camada de busca com IA no agente de consulta, conseguimos aumentar esses valores, quase dobrando todas essas pontuações. E, com os níveis de esforço alto e ultra-alto recém-introduzidos,

20:28 conseguimos uma busca incrivelmente precisa usando o agente de consulta. E há algo que acho simplesmente incrível. Estou muito animado com o futuro disso: pesquisa aprofundada com seus dados. Quem não está animado com esses agents de longa duração, que trabalham, digamos, por 2 ou 10 horas em uma tarefa, e com a possibilidade de direcioná-los aos dados armazenados no seu banco de dados e fazê-los responder a perguntas realmente difíceis, dedicando bastante tempo e capacidade computacional e usando sistemas sofisticados? Acho isso incrível. Então, se você quiser participar, isto está atualmente em fase de prévia do produto. Por favor, há um formulário em

20:59 weaviate.io/productpreviews, caso queira participar dos testes e trabalhar conosco de perto no desenvolvimento. Agora, vamos falar do servidor MCP. Um dos principais objetivos da equipe do Query Agent é integrá-lo aos lugares em que você trabalha. Você pode usá-lo no Weaviate Cloud Console. Pessoalmente, uso muito essa ferramenta. Adoro poder conversar diretamente com meus dados no console, enquanto vejo minhas coleções e navego pelos dados. Acho o console na nuvem incrível. Também é possível usá-lo com o cliente Python e o cliente TypeScript. E agora, com o servidor MCP do Query Agent.

21:31 Isso facilita muito a conexão com ferramentas como Claude Code, ChatGPT, VS Code e Notion, como o Ivan já explicou muito bem, acho. E acho que o que levou a equipe do Query Agent a também entrar nessa foi a forma como as pessoas criam agents usando SDKs de LLMs e frameworks como Pydantic AI, LangChain e DSPy. Então, talvez eu esteja sendo um pouco repetitivo. Acho que o Ivan já explicou isso muito bem, mas um servidor MCP pré-configurado

22:03 significa que você não precisa descrever a ferramenta, fazer o deploy, escalá-la e, provavelmente o mais irritante, mantê-la. Temos apenas esta URL: api.agents.weaviate.io/mcp, e você pode conectá-la imediatamente à sua aplicação. Assim, basta copiar e colar uma linha de código da nossa documentação e adicionar o Query Agent à sua aplicação. Ele acessa os dados no Weaviate usando a nossa camada de IA, diretamente no Claude Code. Você também pode integrá-lo facilmente, mais uma vez, a frameworks como Pydantic

22:33 AI. Ele tem essa abstração de conjunto de ferramentas MCP. É assim que você fornece a lista de ferramentas. E uma coisa muito poderosa que vemos as pessoas fazendo com isso é combinar os MCPs do Weaviate Query Agent com, por exemplo, os dados no Slack, além de acesso de leitura e gravação. Assim, ele pode escrever mensagens no Slack e também no Notion e, digamos, no Google Calendar. Isso oferece uma interface incrivelmente simples para definir esses agents em Python. Se você quiser um controle de nível mais baixo, este é só mais um exemplo de

23:05 como é a sintaxe em outro framework popular: o LangChain. Agora, vamos examinar mais a fundo como criamos o MCP. Vamos manter essas informações na nossa documentação, onde você pode consultar as formas específicas como descrevemos as ferramentas, por exemplo, quantos tokens usamos para explicar ao seu LLM o que os modos de consulta e de busca do Query Agent fazem. Como você pode ver, para o seu LLM — desculpe. Temos esta descrição da ferramenta: o modo de consulta transforma sua consulta em buscas ou agregações acionáveis e, em seguida, fornece uma resposta final à pergunta. Assim, informamos ao LLM o que

23:35 a ferramenta faz. Informamos ao LLM quais são os argumentos de entrada dessa ferramenta, se são obrigatórios ou não, e, em particular, explicamos a avaliação dos resultados. E isso é enviado ao LLM, que então receberá essa resposta ampliada que usamos para combater alucinações e sustentar afirmações verificadas. Em seguida, é isso que usamos no modo de busca para explicar ao seu LLM — ao agent que está usando a API do Query Agent — o que significa fazer buscas com o Query Agent e como isso difere, por exemplo, da busca híbrida ou da busca normal: adicionamos essas camadas extras de reclassificação e

24:06 reescrita de consultas para obter uma busca muito precisa, ao custo de um pouco mais de latência e custo de inference. Mais uma vez, estes são os argumentos de entrada do modo de busca, os diferentes parâmetros que o LLM, o agent, pode controlar. Em seguida, informamos ao consumidor do MCP qual formato de resposta esperar. Para concluir, algumas reflexões sobre criar com MCPs ou usar os clientes Python e TypeScript: acho que, com o servidor MCP, você certamente abre mão de um pouco de controle e personalização, mas a integração fica muito fácil.

24:37 Muitas pessoas já estão criando dessa forma, então faz sentido encontrá-las onde estão. Mas, se você quiser mais controle, recomendo também dar uma olhada nos clientes Python e TypeScript. Há muitas coisas que você pode controlar melhor usando os clientes nativos em vez do MCP. Muito obrigado por ouvir esta apresentação sobre a visão geral do MCP do Query Agent. Adoraríamos conversar com as pessoas para entender que tipo de software estão criando, quais são seus casos de uso e ver como podemos ajudar a usar o Query Agent. Então, por favor,

25:08 entrem em contato por e-mail se tiverem interesse: agentsteam@weaviate.io. >> Connor, obrigado. E, antes de passarmos para Alex, quero avisar a todos que, se tiverem perguntas, podem enviá-las na caixa de perguntas e respostas ou no chat. Vamos respondê-las depois que Alex terminar a parte dele. Já recebemos algumas perguntas boas. Então, sem mais demora, vamos passar para Alex Ledbetter, que é

25:40 o fundador e CEO da Delegance Brokerage. Uma história incrível e muito relevante para construir com IA. Alex, acho que trabalhava em uma corretora de seguros comerciais, e o que mais chamou a atenção dele foi o quanto a IA era pouco utilizada — praticamente nada — na época. Ele viu uma oportunidade de transformar o setor de seguros comerciais por meio da aplicação de IA e

26:11 isso o levou por um caminho que o fez criar, com vibe coding, um negócio de corretora de seguros comerciais Agentech no ano passado e lançá-lo. E, como vocês sabem, ele fez isso sozinho e, ontem, anunciou uma ótima rodada de financiamento pré-seed. Agora, está decolando e crescendo. Então, agradeço muito por Alex estar aqui hoje para contar sua história e, sem

26:42 mais delongas, vamos ouvir. Obrigado, Andy. Não, e obrigado, Connor e Ivan, por fazerem um ótimo trabalho amarrando tudo isso. E muito obrigado por me receberem. É ótimo estar de volta. Participei do podcast algumas semanas atrás, então é ótimo aparecer de novo neste webinar. Como Andy estava dizendo, comecei em uma empresa de seguros comerciais no verão de 2023. Na verdade, eu estava entrando no verão antes do último ano da faculdade. Estudei em uma faculdade de artes liberais, onde fiz economia e inglês.

27:12 Eu nunca tinha escrito uma linha de código nem lido uma linha de código antes de março de 2025. E acabei levantando cerca de US$ 200 mil com investidores-anjo em fevereiro de 2025 para levar isso adiante. Percebi que não tinha recursos suficientes para contratar ajuda externa, então teria que me aprofundar nos detalhes e construir o produto da melhor maneira possível sozinho. Então, não era o ideal. Era

27:43 o começo da era do vibe coding. Naquela época, acho engraçado falar de algumas dessas coisas agora, mas ainda não tínhamos o modo de planejamento — ele só chegou no outono daquele ano. Também não tínhamos context windows bons nesses modelos até mais ou menos o verão. Então, era uma luta tentar manter todo o contexto e seguir em frente, e foi assim que encontrei a Weaviate. Tornou-se muito importante que o modelo tivesse acesso imediato a todos os diferentes sistemas e ferramentas que eu estava tentando usar.

28:15 Então, o servidor MCP da Weaviate foi uma parte essencial da construção da nossa infraestrutura. Este é o nosso site. Vou mostrar a vocês o processo de integração e falar um pouco sobre como estamos usando a Weaviate e onde a estamos usando. No fim das contas, descobri que aproveitar esse tipo de arquitetura de banco de dados vetorial desbloqueia recursos de atendimento mais sofisticados do que os que muitas corretoras e seguradoras usam hoje. Então, vamos passar por isso. Há muitas informações que você precisa fornecer às seguradoras para obter cotações.

28:46 Mas, no fim das contas, descobri que essas corretoras de seguros cobram comissões anuais de 15% a 35%. E, com esses recursos de atendimento que a Weaviate ajuda a viabilizar, é possível reduzir o custo de atender essas contas de uma forma que me permite cobrar menos pelos serviços de corretagem e ajudar essas empresas a economizar nos prêmios de seguro, simplesmente reduzindo as comissões. Então, estou passando por isso. Mas usamos todas essas informações para criar uma

29:21 base de conhecimento abrangente para cada segurado. Então, desta vez, não vamos usar um site. Mas, depois que eu inserir este OTP, vamos carregar nossos documentos. Uma parte importante dos recursos avançados de atendimento e da criação dessa base de conhecimento é que todas essas empresas têm documentos. Elas têm esses fichários. Têm essas apólices.

29:53 Tenho certeza de que muitas das empresas de vocês têm apólices de 200 páginas, talvez de 50 a 200 páginas, que ninguém nunca leu. Há muitas letras miúdas que ninguém entende. E acho que esse é um motivo convincente para aproveitar esse tipo de arquitetura, porque é possível obter respostas em tempo real para todas as perguntas relacionadas às apólices. E outra coisa que também quero dizer é que essa não é a única maneira de interagir com a nossa plataforma. Temos recursos de atendimento disponíveis por e-mail, temos

30:24 um SDK completo, um app do Slack e um app para iOS. E uma das grandes vantagens da Weaviate é que, com os esquemas de dados personalizados que podemos criar, foi muito fácil expandir nosso sistema de memória para diferentes canais. Consegui marcar as atividades do portal, do e-mail e do telefone separadamente. Então, ter um sistema de memória unificado entre todos os canais pelos quais os clientes interagem com a nossa plataforma foi muito importante.

30:55 Isso porque todos esses clientes têm maneiras diferentes de conversar com seus corretores. Então, eu queria tornar a experiência o mais simples possível. Como vocês veem aqui, alguns dados já estão começando a aparecer. O que estamos fazendo, falei um pouco mais sobre isso no episódio do podcast, é converter todas essas páginas de PDF em imagens

31:27 e usar vários tipos de OCR. Não gosto de OCR simples para esse tipo de documento. Acabamos encontrando muitos gráficos e tabelas. E, como Connor comentou, a capacidade da Weaviate de indexar imagens e fazer consultas nelas também é muito importante para os nossos casos de uso. Como vocês veem aqui, extraímos muitas informações desta apólice. Na verdade, podemos classificar muitos tipos diferentes de documentos. Então, há vários agents fazendo coisas diferentes para

31:58 cada tipo de documento. O primeiro esclarece quais desses tipos de documento acabaram de ser carregados, porque o objetivo aqui é que nenhum dos meus clientes precise ser especialista em seguros comerciais. Não quero que eles precisem saber o que são todas essas coisas ou o que têm. A maioria não sabe. Quero que meus clientes simplesmente possam enviar seus fichários. Nós classificamos tudo para eles. Se souberem que algo está errado, podem corrigir. Mas, com base no documento que classificamos, procuramos certos tipos de dados estruturados.

32:30 Também vetorizamos tudo, enquanto criamos um índice para cada tipo de documento. Então, tudo isso está sendo processado. Extraímos informações importantes de todas as apólices: todas as coberturas adicionais, os limites de cada tipo de cobertura adicional e a franquia de cada tipo de cobertura adicional. Tudo isso é extraído. Vocês viram que foi bem rápido. Queremos que as pessoas consigam passar por isso rapidamente. Não vamos fazer isso agora, mas há uma

33:01 opção para responder a algumas perguntas adicionais, fornecer um pouco de contexto sobre seu portfólio e, em seguida, receber uma auditoria completa: por exemplo, talvez haja cobertura excessiva aqui, algumas otimizações possíveis aqui e algumas redundâncias aqui. Isso oferece esse nível de análise, mas também é possível ir direto para uma solicitação de cotação. Atualmente, trabalhamos com cerca de 25 seguradoras. E o objetivo

33:32 é tornar o processo o mais simples possível para que nossos segurados respondam às perguntas necessárias para obter cotações. Essa também é uma parte importante do processo de extração: podemos extrair todos esses detalhes e todas as informações que talvez você já tenha em um conjunto de documentos. Assim, você não precisa inserir as informações de novo, porque podemos aproveitar o que extraímos e o que você forneceu para ajudar a transferir essas informações entre

34:03 é tornar isso o mais simples e integrado possível para que nossos segurados respondam às perguntas necessárias para obter cotações. Então, essa também é uma parte importante desse processo de extração: podemos extrair todos esses detalhes, todas as informações que talvez você já tenha em um corpus de documentos. E assim, você não precisa inserir as informações novamente, porque podemos aproveitar o que extraímos, o que você forneceu, para ajudar nessa transferência de informações entre

34:33 entre empresas seguradas e seguradoras. Vejo meu trabalho como corretor: é basicamente uma transferência de informações com alguns recursos de atendimento incorporados. Mas construímos uma plataforma completa, então não tentem acessar essas coisas. Não vai funcionar a menos que vocês tenham uma conta de verdade. Colocamos tudo isso em uma lista de permissões, mas vocês podem entrar e enviar mensagens para um agent de IA, ligar para um agent de IA,

35:04 enviar e-mails para um agent de IA. Vocês podem agendar um horário comigo. Temos todas as nossas integrações aqui, então nossos servidores MCP são nosso PWA. Temos um app para iOS. Preciso descobrir como colocá-lo aqui. Temos nosso app do Slack. E também temos um SDK completo, então venho trabalhando em um produto de CLI também. Não sei vocês, mas minha experiência ao contratar um seguro comercial antes disso era meio ridícula. Eu precisava entrar, preencher um formulário, e

35:35 esperavam que eu participasse de uma ligação de 30 minutos com um subscritor, respondendo a mais perguntas. Então, eu queria criar uma experiência em que fosse possível fazer tudo por conta própria, tudo o que vocês pediriam ao corretor para fazer. Em vez disso, vocês podem resolver tudo em tempo real, porque temos 142 ferramentas MCP voltadas para o cliente. Então, qualquer informação qualitativa que recebemos de um segurado pode acionar uma

36:06 atualização automatizada da apólice, um novo COI, um comprovante de seguro, basicamente qualquer coisa de que um cliente possa precisar. Em vez de ter que falar com alguém ou esperar por essa pessoa, digo às pessoas que isso é muito melhor do que o corretor de seguros comerciais médio, que tem 60 anos. Então, esses caras nem sempre têm mais familiaridade com tecnologia e nem sempre são os mais rápidos. Portanto, ter algo que possa atender vocês em tempo real, integrado a um sistema de memória que, sabe, é tão bom quanto a memória fotográfica de uma pessoa,

36:37 é mais fácil de vender para empresas que querem economizar, querem um custo-benefício melhor e simplesmente querem recursos de atendimento melhores. Então, acho que isso eleva o nível do que as empresas deveriam esperar. Esta é minha imitação do DocuSign. Vocês podem assinar acordos de corretor responsável dentro da nossa plataforma, e isso aciona processos subsequentes. Também criei um sistema completo de gestão de agência integrado a isso. Então, isso

37:08 é enviado. O acordo de corretor responsável permite que vocês solicitem COIs em linguagem natural por todos os diferentes canais. Vocês podem adicionar mais pessoas à empresa, e também oferecemos suporte a múltiplas entidades. Então, se vocês tiverem várias entidades, podem aproveitar a infraestrutura de base de conhecimento aninhada que construímos. Esse é outro ótimo caso de uso para Weave AI: se vocês tiverem estruturas com várias entidades complexas ou requisitos de lógica aninhada, isso é muito útil para criar esse tipo de parâmetro para diferentes locatários.

37:40 E vocês podem acessar tudo isso praticamente a qualquer momento. Podem abrir todos os documentos que acabamos de carregar e fazer perguntas sobre eles. Sabe, podem usar o índice para filtrar diferentes itens. Temos um histórico completo de conversas, então vocês podem filtrar quando as consultas foram enviadas e por onde foram enviadas. Ou seja, qual canal vocês estavam usando? Podemos rastrear

38:10 tudo, com exceção do OpenAI e da Anthropic, que não nos permitem obter as transcrições dos chats. Eles nos permitem obter as chamadas de ferramenta utilizadas. Isso é menos bom, mas o objetivo é que, não importa onde vocês estejam, possam aproveitar os mesmos recursos de atendimento. E vou falar sobre isto: “O que você pode fazer por mim?” Provavelmente vai listar a maioria deles. Mas, sim, coisas como analisar sua cobertura, dar suporte a sinistros hipotéticos

38:40 e identificar dados estruturados nos seus documentos. Tudo isso está disponível para 36 tipos diferentes de cobertura e também para mercados de títulos. Temos visto muita demanda de empresas que acham que isso oferece um custo-benefício melhor do que o que existe hoje, especialmente empresas com quem conversei que dizem: “Ligo para meu corretor uma vez por ano. Pago alguns milhares de dólares por ano em seguro comercial,”

39:12 e, sabe, converso com ele uma vez por ano. Essa é a ligação telefônica mais cara que faço em todo o ano. São dezenas de milhares de dólares. Então, poder economizar dinheiro e resolver tudo de ponta a ponta é um pouco mais… é mais poderoso, mais rápido e acho que há muitas empresas que, especialmente à medida que mais empresas começam a usar agents, vão querer isso. Pessoalmente, eu nunca gostaria de cuidar do meu próprio seguro comercial.

39:44 Prefiro passar isso para o Claude ou para o OpenAI e nunca mais ter que pensar nisso e, sabe, aproveitar todos os contatos que tenho na região. Então, é mais ou menos assim que venho tentando desenvolver as coisas. Também temos soluções integradas de financiamento de prêmios. Então, se vocês precisarem de financiamento no ponto de venda, também oferecemos isso. Podemos ajudar a agilizar o processo de envio de sinistros. Não sei até que ponto queremos aprofundar tudo isso, mas também posso falar sobre as diferenças entre MCP e APIs e sobre onde o MCP

40:16 se destaca em comparação com outras soluções. Sim, mas… >> Vamos começar a falar sobre como isso foi construído. É incrivelmente impressionante e uma observação muito boa. Quer dizer, seguros, e seguros comerciais em particular, envolvem um processo e um negócio com muitos documentos, o que é uma combinação muito natural para IA. Trata-se realmente de extrair informações e respostas de grandes documentos de seguro para responder às perguntas dos clientes e tomar decisões sobre com quem eles finalmente

40:46 vão contratar o seguro. Mas, sim, vamos começar um pouco com as perguntas e respostas. Começaremos com perguntas para você, Alex. Recebemos algumas perguntas sobre por que Weaviate. Por que eu usaria Weaviate em vez de PG Vector? Ou por que usaria em vez de outros bancos de dados vetoriais? Vou dar uma resposta rápida e depois deixo o Alex dar a resposta dele, já que foi ele quem tomou essa decisão na prática. E acho que, em relação a

41:17 algo como PG Vector, tudo se resume à melhor ferramenta para o trabalho. O Weaviate foi criado especificamente para casos de uso como o do Alex. O que vocês vão notar no PG Vector é, em primeiro lugar, a experiência do desenvolvedor. Como o Weaviate pode integrar os modelos diretamente ao banco de dados, isso significa muito menos código para mover dados e muito menos desenvolvimento de pipelines para transferir dados entre o banco de dados e os modelos. Toda a vetorização e a geração de embeddings podem acontecer dentro do banco de dados, o que simplifica o desenvolvimento. E, em termos de execução e consultas, à medida que o banco de dados cresce, indexar os dados vetoriais no PG Vector vai se tornar dolorosamente lento. Com o Weaviate, graças à maior variedade de opções de indexação, compressão e consulta, ele consegue escalar e ter um desempenho melhor em praticamente qualquer escala. E, como parte do material de acompanhamento,

41:47 vou compartilhar o link de uma publicação no blog que a booking.com publicou há apenas algumas semanas, explicando exatamente por que decidiu centralizar todas as aplicações vetoriais no Weaviate, migrando muitas delas do Elasticsearch ou do OpenSearch, e incluindo alguns resultados de benchmark que obtiveram. Vou compartilhar isso no material de acompanhamento. E, em relação a bancos de dados vetoriais como o Pinecone, novamente, geralmente é a experiência do desenvolvedor que

42:18 diferencia o Weaviate dos outros. Além disso, há opções de deploy e recursos como multilocação, algo nativo que o Weaviate faz muito bem. E também há as opções de deploy: se estamos falando especificamente do Pinecone, ele é um serviço disponível apenas na nuvem, enquanto o Weaviate pode ser instalado e executado onde vocês quiserem. Mas, Alex, você teve que tomar essa decisão uma vez. Qual foi seu processo de decisão? >> Então, vou dizer que eu já tinha alguma experiência, por exemplo, em

42:48 distingue a Weaviate das outras. Além disso, os recursos de implantação, como a multitenancy, são algo nativo que a Weaviate faz muito bem. E também há as opções de implantação: se você estiver falando especificamente da Pinecone, ela é um serviço disponível apenas na nuvem, enquanto a Weaviate pode ser instalada e executada onde você quiser. Mas, Alex, qual foi a sua, sabe, você já precisou tomar essa decisão. Qual foi o seu raciocínio? >> Então, eu diria que já tinha alguma experiência, tipo, em

43:19 Entre 2025 e, quando me formei, nós estávamos sendo construídos… Eu trabalhava como gerente de produto de IA em uma empresa de consultoria que criava bases de conhecimento personalizadas. É engraçado que, poucos anos atrás, muitas grandes empresas pagavam por isso, mas não sabiam como criar suas próprias bases de conhecimento personalizadas. Então, estávamos aproveitando… Os engenheiros chegaram recomendando imediatamente o Weaviate. Nós

43:49 tínhamos tentado usar outras soluções, mas a configuração era complexa demais, e precisávamos de algo que, no fim das contas, pudéssemos entregar para essa grande empresa. Então, eles precisavam de algo que pudessem hospedar por conta própria. E o fato de o Weaviate ser tecnicamente open source e estar disponível nos permitiu criar toda a infraestrutura necessária do nosso lado antes de entregá-la a esse grande

44:20 cliente. Então, isso foi muito importante. Na época, acho que provavelmente ainda é assim, mas analisamos… Era tecnicamente possível. Acho que ainda é, talvez tenha ficado um pouco mais fácil, mas analisamos o RDS como solução com a AWS, e foi um pesadelo alinhar todas as tags de metadados do jeito que precisávamos. Então, algo como o Weaviate… Para mim, muitas dessas coisas se resumem a: com que rapidez você consegue avançar? É fácil de configurar? Seu agent consegue configurar isso para

44:51 você? E o Weaviate consegue fazer… conseguia fazer tudo isso antes de muitos concorrentes e continua muito na vanguarda, eu diria, em termos de agents de consulta. Não há muitas plataformas com consultas integradas prontas para uso, especialmente com esse nível de qualidade. E acho que… Sei que eu tinha um executivo de contas dedicado, o que era muito importante para mim na época. Tipo, eu nem

45:23 tenho executivos de contas no meu banco agora. Então, ter esse tipo de suporte técnico prático como vibe coder também foi muito importante para mim. Houve momentos em que meu executivo de contas conseguia me fornecer recursos e documentação para diferentes problemas que eu estava enfrentando, e eu podia simplesmente inserir esse contexto diretamente no meu agent para me ajudar a resolvê-los. Então, também consegui um bom nível de suporte do Weaviate.

45:55 Não sei se outras empresas oferecem esse tipo de recurso ou suporte a todos os clientes. Essa é só a minha experiência, e também há muitas outras questões técnicas. Eu escrevi algo no chat sobre isso, mas a flexibilidade do schema também é muito importante. Quando você tem muitas dessas ferramentas prontas para uso, que são bem simples, elas podem acabar sendo um tanto limitantes por serem tão padronizadas. Por exemplo, nunca considerei o N8N

46:25 por esse motivo. É… Sim, acho importante ter essa flexibilidade. Essa é a minha opinião. >> Obrigado. Vamos ver outra pergunta para Yvonne. Os servidores MCP… Você pode falar um pouco sobre a disponibilidade deles? >> Claro. Se a pergunta é sobre open source, o servidor MCP do banco de dados Weaviate é, claro, open source, então faz parte do

46:56 próprio banco de dados. Se você iniciar seu próprio cluster, ou mesmo se usar o Weaviate Cloud, ele estará disponível por padrão. Não precisa configurar nada, não há taxas nem nada do tipo. O query agent é um serviço separado que oferecemos. Como parte do Weaviate Cloud, oferecemos um número gratuito de solicitações, ou consultas, que você pode enviar ao query agent, mas ele não é open source. É um serviço gerenciado.

47:26 >> E acho que outra pergunta é: vocês conseguem se conectar a ele pelo Cloud Desktop? >> Sim, claro. Você também pode configurá-lo em… Não tenho certeza onde: nas configurações, em Preferências, no aplicativo Cloud Desktop. Eu mesma experimentei, e deve funcionar da mesma forma que com o Cloud Code. >> Ótimo. E uma pergunta para você, Connor. Acho que você respondeu isso na caixa, mas é só para a gravação. Alguém queria saber mais sobre

47:56 os resultados da avaliação da resposta final: se é parcial, se faltam informações e quais são as fontes. >> Ah, sim, ótimo. >> Esclareça a pergunta e responda. Sim. >> Ah, sim, legal. Então, ter geração fundamentada e garantir que as respostas não sejam alucinações, mas sejam realmente baseadas nos dados do seu banco de dados, é um dos nossos principais focos no query agent. A forma como resolvemos isso até agora é com um argumento opcional na avaliação do resultado. Você pode desativá-lo

48:28 se não quiser gastar com o custo extra de inference. Mas, quando está ativado, o que fazemos é aplicar outra inference de LLM à resposta final. Ajustamos e otimizamos esse LLM para avaliar a resposta final com o contexto recuperado, analisar e preencher campos como se a resposta é parcial, se faltam informações e, então, validar as fontes que ela retorna nesse atributo de resposta estruturada. Essas são algumas das coisas que estamos fazendo para combater alucinações e garantir que esta seja uma API de geração aumentada por recuperação realmente confiável. E

48:58 nós adoraríamos trabalhar com você. Se você não encontrar o que procura, se houver alguma adição específica que queira ver ou algum teste que tenha, entre em contato conosco. Adoraríamos ver como podemos ajudar ainda mais. >> Ótimo, obrigado. Alex, uma pergunta sobre sua stack. O que mais faz parte da sua stack de vibe coding e programação com IA, além do Weaviate e dos zilhões de servidores MCP aqui? >> Sim, eu diria que estou sempre buscando otimizar. Até agora mesmo, eu

49:30 há duas semanas, depois do nosso podcast, descobri, Connor, que aquilo que eu estava descrevendo tem, na verdade, um termo técnico. Vindo de uma área não técnica, percebi que muitas coisas que criei ou simplesmente intuí que precisaria ou desejaria foram construídas, de certa forma, a partir de princípios básicos. Muitas delas já existem ou têm nomes técnicos, então tenho redescoberto algumas coisas e

50:02 quero falar sobre a nossa fábrica de software que construí. Mencionei isso nos comentários, mas, quando eu fazia vibe coding, passei sete… Passei de sete a oito meses construindo antes de a primeira empresa entrar na minha plataforma. Percorri meu próprio fluxo de experiência do usuário mais de 700 vezes. Por isso, em muitas dessas iterações, era essencial usar ferramentas ou infraestrutura que eu pudesse controlar ou

50:33 inserir contexto facilmente nos meus agents pelo terminal. No ano passado, fiz tudo no Cursor. Eu estava entre os 5% de maiores usuários do Cursor no ano passado, mas no começo do ano mudei para o Claude Code, como acho que muitas outras pessoas fizeram. Então… Ah, preciso perguntar: minha plataforma é agentic first? Sim, é. Integrei o web MCP. Também queria mencionar isso. Web MCP… Sei que há opiniões fortes sobre MCP versus

51:04 API versus CLI. Uma coisa que sei com certeza é que o web MCP é uma infraestrutura essencial se você quer que tudo seja pensado primeiro para agents. Ele permite que agents de navegador que visitam sua plataforma ou seu site usem todas as funcionalidades com mais facilidade do que se tivessem de ficar fazendo um ciclo de capturas de tela, tentando continuamente encontrar os campos certos em um formulário ou localizar a funcionalidade certa na sua

51:35 página. O web MCP é ótimo para isso. É assim que tenho tentado construir. Acho que estamos caminhando para um mundo em que, pelo que li, até 2030 devemos ver de três a cinco trilhões em pagamentos processados por meio do comércio com gen tech. Então, estou prevendo esse cenário. Acho que tem havido muita movimentação com agents pessoais nas últimas semanas, mas aposto que, nos próximos anos, veremos em breve a adoção por empresas e por grandes corporações, seguindo essa tendência.

52:08 Há muitas operações de back office ou tarefas administrativas para as quais as pessoas prefeririam recorrer a agents, e os agents já são muito bons nisso, sabe, especialmente em arquiteturas multi-agent. Acho que é possível reduzir o risco de alucinações ou de algo dar errado se houver vários agents analisando os resultados e colaborando entre si. Isso dificulta a injeção de prompt. Também dificulta que os resultados pareçam ruins e, certo…

52:40 Agora os custos estão caindo. Então, acho que, no longo prazo, haverá muitas arquiteturas multi-agent. Vejo isso como uma prova em que há dois alunos que tiram, em média, cerca de 80%. Sabe, vamos manter uma estimativa conservadora. Então, OpenAI e Claude, ou Anthropic, são alunos que tiram 80%, e fazem uma prova juntos. Juntos, não há sobreposição. Então, na verdade, eles…

53:12 tiram uma nota mais alta na prova quando trabalham juntos. Então, eu estava… vejo alguém falando bastante comigo no chat também. Mas, sim, o Superbase foi ótimo. A AWS foi ótima. A CLI da AWS foi ótima. O Superbase foi muito útil. Minhas definições de tarefas estão explodindo com as diferentes ferramentas que estou usando. Mas essas provavelmente são as…

53:43 principais. Acho que, sabe, usei Weaviate, AWS e o Superbase foi outra plataforma que usei. Mas, se eu fosse fazer de novo, não teria percebido que era possível usar Weaviate para dados estruturados. Connor e eu também conversamos um pouco sobre isso. Se eu fosse fazer de novo, simplificaria e usaria Weaviate para dados estruturados e não estruturados. E isso seria ainda melhor, porque eles estariam nos mesmos sistemas, o que facilita a recuperação e a manutenção das informações no context. Uma chamada de ferramenta a menos que poderia dar…

54:14 errado, uma consulta a menos que poderia dar errado, uma dependência a menos. >> Legal. Certo, chegamos ao fim da hora. Quero agradecer a Connor, Yvan e Alex por terem reservado um tempo hoje. Gostei muito das informações. Espero que todos na audiência também tenham gostado. Enviaremos um link para a gravação deste evento para quem perdeu alguma parte. Também enviaremos links para outros recursos, como a entrevista de podcast entre Connor e Alex, em que…

54:44 Alex fala com mais detalhes sobre a criação do Delegates, e compartilharei o link para a publicação do blog da booking.com, em que eles falam sobre a padronização do uso do Weaviate para suas aplicações de IA. E, com isso, esperamos ver vocês novamente em um evento futuro. Muito obrigado a todos por participarem hoje. Tchau. >> Obrigado a todos. >> Tchau. >> Obrigado a todos.

Transcrição original

[00:03] Right. Hi everybody and welcome to today’s webinar inside the Weaviate MCP ecosystem. I’m Andy Ellicott and my co-presenters today include Ivan and Connor from Weaviate engineering and we also have Alex Ledbetter, the CEO and founder of Deligence brokerage who’s going to talk about his experience using vibe coding with Weaviate. Our agenda today is starts with a quick introduction of overview of Weaviate in case you’re new to it and following that

[00:35] Ivan will talk about the new MC server MCP server for the Weaviate database followed by Connor who’s going to explain the MCP server for the Weaviate query agent and we’ll wrap up with Alex talking about how he I think single-handedly and without much if any computer science experience vibe coded a commercial insurance brokerage business into existence in under a year and I think yesterday

[01:06] just announced his pre-seed round of funding. So he’s off to a great start and his his story is really interesting and very relevant to anybody here who’s has come to this event hoping to learn more about AI assisted coding and operations of Weaviate. We’ll wrap up with Q&A and if you have any questions at any time during the webinar use the Q&A button on your Zoom screen and we’ll go through those at the end. We’ll get through as many as time

[01:36] allows. And since one of the most common questions we get is will this be recorded and shared? Yes, it will. The event today is being recorded and we’ll share a video recording of this after the event in case you’d like to revisit any of it or share it with others. All right, so let’s start with a quick introduction to Weaviate for those of you who are new to it. Uh Weaviate is an open source vector database. It’s built specifically for AI use cases like semantic search, generative AI, rag, AI inference, agentic AI, and many others.

[02:08] It makes building AI applications exceptionally easy uh because it’s purpose-built for indexing and uh uh very, very quickly searching vector data for those types of applications. Uh it’s also uh very capable of scaling and performing fast enough to support uh really large-scale AI initiatives as it does at Weaviate customers like Booking and Cisco and and many others. Weaviate is uh part of a platform that includes a

[02:38] couple of other components including the query agent, which Connor’s going to talk about today. Uh the query agent facilitates natural language querying of your your data. Uh there’s also uh Weaviate embeddings, which is a capability that allows you to plug uh AI models into your um into the database to facilitate and simplify application architectures by facilitating the generation of vector data within the database itself. And finally, Ingram, which is a a newer

[03:10] product which gives you a jump start in using Weaviate for AI memory in personalization, other AI applications. Okay. So, that’s uh that’s Weaviate in a minute. And uh without further ado, let me turn it over to Yevon who will dive into details on the new MCP server for the Weaviate database. >> Thank you for the introduction. So, let’s head straight in. Hi, everyone. I’m Yevon. Um I work on developer

[03:40] experience here at Weaviate, and I help develop the database MCP server. Today, I’ll give you a short overview of the MPC ecosystem we use at Weaviate, uh show you the server that’s built into the database and spend some time in a live demo with V8 Cloud showcasing how to actually use the MCP tools. So, first off, the ecosystem map and a very short intro about MCP for anyone new to it. So, MCP, the Model Context Protocol, is an open standard that lets

[04:11] AI assistants and tools, um, read data and call other tools from outside its system. It started at Anthropic like about 2 years ago and now lives under the Linux Foundation. Um, tools like Claude, ChatGPT, Cursor, all use it. It’s basically a protocol for AI-powered tools to directly communicate with various servers, applications, um, anything you can think of essentially. At the top of the slide, you can see some of the clients you might already be

[04:42] using and underneath are the servers in the V8 ecosystem. Uh, for example, on the left is the V8 Docs MCP server. It’s hosted and powered by Kappa AI and it serves the V8 documentation to your assistant directly. So, for example, if you’re using an AI assistant to, uh, develop some code with V8 and have questions about the API or some configuration values inside V8, instead of a performing a web search, you can ask the Docs MCP server directly and it’s probably be more accurate than trying to

[05:14] fetch the data yourself. Next is the V8 Database MCP server. It’s built directly into the V8 database itself and and it gives your assistant direct access to your own cluster, so you can inspect the schema, uh, search your data, write objects into it, and I’m going to cover that one in more depth in the, uh, next few slides and through the demo. Next to it is the Query Agent MCP. So, instead of querying the database directly using the Database

[05:45] MCP server, you use a dedicated uh, AI-powered agent or assistant that already knows how to turn your questions into the right queries and with much more precision than your AI tool will do it. Conor will talk more about that one later. And you can, of course, also create custom MCP servers if you have a very specific use case that’s not covered by any of the aforementioned ones.

[06:15] So, now let’s talk about the V8 database database MCP server. You can see the architecture of our built-in MCP server. What does built-in mean? There is no package, no extra container, nothing to install. So, when you run V8, the MCP server is already running inside of it and it’s served at /v1/mcp on the same port as the REST API. So, if you follow the arrow from left to right, you can see that your client, for

[06:45] example, Cloud Code or VS Code or an agent, connects over streamable HTTP and sets a regular V8 API key to authenticate against the cluster. Every call goes through the same authentication and Rback as the rest of the API. Every tool is also mapped to a specific permissions. So, if, for example, you give your assistant viewer only key, it only has read-only access to your cluster. So, the

[07:18] AI tool cannot do any destructive operations. Behind the gate, you can see the four currently available tools that are available. And the write tool has a lock on it because by default in the self-hosted V8 version, write access is disabled. You need to enable it yourself. On V8 Cloud, which I will show the demo on. The MCP server is on by default and write access is also on by default, but you can

[07:48] disable it. Or you can provide granular permissions to an API key that you’re using, so the MCP has only access to some restricted data. The four tools that are available are the get collection config tool, so your assistant can learn about what data is inside your cluster, like the properties, which vectorizer you’re using, if multi-tenancy is turned on. The list tenants tool is used for inspecting multi-tenant collections,

[08:20] uh, seeing which tenants are actually part of it. The hybrid query tool combines vector and keyword search, so it’s the main search tool you’re using to retrieve data from Weaviate, and the upsert tool is the main write tool, so you can use it to either insert new data or as an update tool to replace existing data with it. Uh, on the right you can also see the Rback permissions that map to the tools, so you can also provide granular access to what an agent can use.

[08:50] Uh, and now let’s show all of this in action. First, we need a Weaviate cloud cluster. I have already created one, as you can see in the main dashboard. This is the REST endpoint that we’re going to use to connect with the MCP. You can also click on the how to connect button, and here in the MCP tab, you have a command that you can directly run in the tool you are using. This is for cloud code. You also have other options

[09:23] available. I already connected mine locally, so you don’t have to see the API key. Let’s check it out. Now, let’s first check if the connection has been established. I’m going to do it with the MC P command and here I can see that we are connected to V8 cloud. Let’s also check out. This is the rest URL I have showed earlier of the cluster. And here we can also see the tools that are available. This isn’t

[09:55] really of any importance to you as a user. This is what the agent is going to use in the end. For example, this is the description and the parameters that the agent will see and be able to configure on its own. So now let’s actually try a query. Let’s first ask it what is in the V8 cloud cluster. And if everything goes right,

[10:27] as it always does with such live demos, it’s going to use the correct tool. Yes, it’s the V8 collection get config so it can check the schema of the cluster. And now it’s also going to run the V8 query hybrid tool to also check out some of the objects that are stored in the clothing collection. It also found a second collection, a brands collection. It also wants to query that one. Let’s let it.

[11:00] And in just a few short seconds, it should make sense of the data that it retrieved from the cluster. And here we have it. It’s an e-commerce data set with two collections, a clothing one, essentially a product catalog with different clothing items and brands that are associated with those clothing items. So let’s now for example do a realistic query that someone in an e-commerce web application would use. Find me a summer dress for a wedding

[11:35] under 200 bucks. And let’s see how it’s going to interpret this plain language request into a query. Here we see that it’s searching the clothing collection. The query is elegant summer dress for a wedding guest. Uh it’s limiting it to eight results. Here it’s applying specific filters because I said dress. Uh it’s searching in the dress category. The price needs to be less than 200. And

[12:06] because I didn’t uh specify what to return, it’s going to just return all of the properties. Right, let’s run it. Nice, it worked. And I’m going to show you another query. Let’s for example add a product. So, add a new product to the clothing collection with some more details.

[12:39] And it’s again going to construct the tool call. It’s using the objects upserch tool. It populated all of the fields correctly as I can see from a glance. Now, let’s run it. I’m interested to see if it’s going to perform a hybrid search just to check if it worked. And yes, it’s going to do it. Let’s see if it’s going to retrieve it.

[13:11] And I assume it worked. Yes, it added the harbor cashmere crewneck to the clothing collection. It also created the brand. So, here you can see that everything we have tried in plain language has so far succeeded. So, that’s the whole loop. The assistant discovered the cluster on its own. It searched it. It uh looked up the database schema, fetched a few objects from it to understand the context. Um these four tools are currently

[13:43] available, but you can expect us to extend the MCP with additional tools in the future as well. That’s it for me. >> Thanks, Yevhen. Uh next uh if we can uh we’ll switch over to Connor, who’s going to uh dive into detail on the uh MCP server for the Weaviate query agent. >> Awesome. Well, uh thanks so much for the introduction, Andy, Yevhen, Alex, Laura for putting together things. Everyone for being here. I’m super excited to

[14:13] dive into Weaviate’s query agent. Uh talking about some things that are what’s new and then anchoring with our MCP server, so one of the newer additions to Weaviate’s query agent. So, quick highlight of what’s new, structured outputs, retrieval augmented image generation, effort here’s research mode in our query agent MCP server. So many exciting things. It’s just been so fun to work on. I’m just so excited about this. So, before diving into what’s new, let’s maybe do a quick background for people who aren’t already familiar with the query agent. Uh retrieval augmented generation is about grounding the generations from AI

[14:45] systems in your particular data. Imagine asking a question like, “Which waterproof jackets under $200 are in stock?” That’s like a completely nonsensical question to just ask an LLM. The answer is completely about being grounded in your data. And there’s all sorts of examples of having private data, mixing your internal data with public knowledge. Just all these things of having retrieval augmented generation to supplement these generations and things like hallucination verification, making sure that the outputs coming from the systems are actually supported by the data in your Weaviate database.

[15:16] So, the query agent is built for RAG with Weaviate. It’s a agent that’s co-designed with the database. And there are all sorts of interesting ways that that uh manifests itself. Some of the biggest areas are schema understanding, query writing, and then these AI layers that we integrate into these applications like arbitrary generation or say chatbots or search or research, which is say re-ranking, long context handling, and then grounded generation and hallucination checking. So, I’d quickly go through some of these core features of the query agent.

[15:47] Schema understanding is maybe the best example of this co-design in addition to the kind of like text SQL part of it. But, um we have so we look at the collection schemas, we know how to parse what comes back from Weaviate’s meta APIs to turn it into a prompt as well as a structured output for writing Weaviate queries. We have the data sampler, how we inspect some of the data. Then we have the filter inspector where we look at the distribution of values of these filters. So, for example, if you have I love this example of having say Pokémon games where you might have a property on color, and just color alone the LM would

[16:18] have no idea that the particular values it takes on are ruby, sapphire, and emerald. So, it’s an example of how we can co-design the agent to give it information about the data in your data to fit in your database to facilitate these AI applications. So then, uh translating user questions to Weaviate queries is kind of translation of your natural language questions into structured Weaviate queries, being able to write search queries, uh use filters to retrieve objects, combine searches and filters, and then apply aggregations to your data. So, say you have a numeric

[16:48] property on price, you can calculate the average price of that in Weaviate like you would be able to in a relational database. Weaviate also has very strong support for structured data. So then, we have some AI layers on top like re-ranking, handling long context. So, say some of the objects that come back from Weaviate are just these massive objects or you’re retrieving images from the database, the query agent is able to read your images, whether that’s like brand assets, graphics, or say PDF pages, you can read these in the query

[17:18] agent as well as handling long conversations. And then a huge part, just critical part of these AI applications is grounded generation, making sure every answer is checked against your data, and you don’t have to worry about hallucinations with the query agent. So with this core, we then have four modes, four applications that we deliver on top of this functionality. We have ask mode, search mode, suggest queries mode, and research mode. So these are different ways to use the query agent. Ask mode is sort of a a a pretty general, like the responses API from

[17:50] OpenAI’s LLM SDKs, where you can do a lot of things with it. And search mode is us unpacking the under the hood search layer and offering that natively to just use it for search. Suggest queries is a helper with building chatbots where we it’s like a helpful thing with the developer with the with the experience of someone going through your chatbot to suggest some queries to them that your data can answer, as well as suggesting follow-up queries when you’re building chatbots and you have these long conversations. And then research mode, I’m just so excited about research mode. I think it’s just such an incredible technology.

[18:22] So the query agent, we built it with customization in mind. We have a lot of features to help you adjust it to what you need. You can import a custom system prompt. You can set your effort tiers. And then we have particular things like if you want to really fine-grain control over the filtering that the query agent is going to be using as it’s looking through the data in Weaviate. So awesome, now diving into some of the new things we’ve been up to. I think all these things are just extremely cool. So starting off with structured outputs. Structured outputs are this really cool way when you have an LLM generating

[18:54] anything, you can particularly type the outputs that it’s going to be producing. So say it’s going to be picking a jacket, and it’s going to have a name, a price, and whether it’s waterproof or not. We’ve now added support for structured outputs with ask mode. And a super super awesome part of this is how we’ve added retrieval augmented image generation. So, one of these structured outputs can be an image. So, this is the most popular example internally that we use, creating an advertisement of our mascot wearing our best-selling sweater, and you get this

[19:25] awesome kangaroo in a orange cardigan. So, the query agent is able to look at your data to find out who our mascot is. It could be images of this kangaroo guy, and then it could be and then it looks through your images to find what our best-selling sweater is. So, our best-selling sweater is demonstrating this capability of sorting the objects by how many sales they have to retrieve that kind of information, combining this for retrieval augmented image generation. I’m just so excited about the potential of this. So, then we have the effort tiers that have firstly landed in search mode. To

[19:57] give you a sense of what this means, we benchmark this on a search benchmark where basically you’re evaluating how accurate the search results are given your collection of say, in this particular case it’s about 500,000 documents, is the gold or the human annotated correct document in the say top 1, 5, or 20 results? Hybrid search by itself produces these numbers. Using the AI search layer in the query agent, we’re able to boost this up, nearly doubling all these scores. And then using the newly introduced high and ultra-high effort

[20:28] tiers, we’re able to just get incredibly accurate search by using the query agent. And then just something I think is just amazing. I’m so excited about the future of this is deep research with your data. Who isn’t excited about these long horizon agents, that work say for 2 hours, 10 hours on a task, and putting that pointing that at the data that’s stored in your database, and having it answer these really hard questions, spending a lot of time and compute, and using sophisticated systems. I just think this is awesome. So, if you this is currently in a product preview stage, please there’s a form on

[20:59] weaviate.io/productpreviews if you want to join the testing with this and work with us closely on the development of this. So, now diving into the MCP server, a core focus of us with the Query Agent is integrating this wherever you work. We have You can use this in the Weaviate Cloud Console. Personally, I’m a huge user of that. I love being able to talk to my data directly in the console where I’m looking at my collections and looking through my data. So, I think the cloud console is just incredible. As well as this Python client and TypeScript client. And now MC Query Agent MCP server.

[21:31] So, this makes it really easy to connect with as Ivan, I think, already gave an incredible explanation of this with Claude Code, ChatGPT, VS Code, Notion, these kind of GUI tools. As well as really, I think, what pushed us to get on get in on this as well with the Query Agent team is the how people build and build agents with LLM SDKs, frameworks like Pydantic AI, LangChain, and DSPy. So, again, kind of maybe maybe a little redundant. I think Ivan already Ivan already gave a great explanation of this, but I’m a pre-built MCP server

[22:03] means that you don’t need to describe the tool, deploy it, scale it, and probably most annoyingly is maintaining it. We just have this URL api.agents.weaviate.io/mcp, and you can just instantly plug this into your application. So, that makes it just this one line of code to just copy and paste this from our docs and add in your the Query Agent accessing data in Weaviate using our AI layer around it right into Claude Code. You can also easily integrate this with, again, these frameworks like Pydantic

[22:33] AI. has this MCP tool set abstraction. So, this is like how you give them your list of tools and the super powerful thing that we’re seeing people doing with this is they say combine the Query Agent Weaviate MCPs with, say, their data in Slack as well as, you know, read write access. So, it might be able to write messages in your Slack as well as Notion, say, Google Calendar. And so, you have this incredibly simple interface for how you would define these agents in Python if if you want lower level control over this, this is just another example of

[23:05] just showing what the syntax looks like for another framework, another popular framework, which is LangChain. So, now going a little deeper into the hood of how we build the MCP. So, we’ll be maintaining this on our docs, and you can find the particular ways that we’re describing the tools, say how many tokens we’re using to describe what the query agent’s ask mode and search mode are doing to your LLM. As you can see for your LLM, I’m sorry. So, we have this tool description, ask mode transforms your query into actionable searches or aggregations, and then provides a final answer to the question. So, we’re telling the LLM what

[23:35] the tool does. We tell the LLM what its input arguments are for this tool, whether they’re required or not, and particularly the result evaluation. And this is it to LLM, then and it will get this expanded response that we’re using to fight hallucinations and support verified claims. So, then this is what we use for search mode to explain to the to your LLM, your agent that’s consuming the query agent API, what it is about search searching with the query agent, how it’s different from say hybrid search or normal search, this idea that we’re adding these extra reranking and

[24:06] query writing layers to get super accurate search at the cost of a bit more latency and inference cost. So, then again, these are the input arguments to search mode, different parameters the LLM the agent has control over, and then we tell the the consumer of the of the MCP what response format to expect. So, concluding with some thoughts on building with MCPs or using the Python and TypeScript clients, I think the MCP server you definitely give up a bit of control and customization when you’re

[24:37] using the MCP server, but then it just makes it so easy to integrate. A lot of people are already building this way, so it makes sense to just meet them where they’re at. But, if you do want more control, I do recommend also to seeing the Python and TypeScript clients. There are a lot of things in there that extra control over with using the native clients instead of using the MCP. So, thank you so much for listening to this talk on the Curry Agent MCP overview the Curry Agent. We’d love to connect with people to understand what kind of software you’re building, your use cases, and see how we can help you use the Curry Agent. So, please just

[25:08] email us if you’re interested in that at agentsteam@weaviate.io. >> Connor, thanks. Um and uh before we uh as we switch over to Alex, uh I just want to let everybody know that uh if you have questions, please enter them into the Q&A box or in the chat. We’ll get to those after uh Alex finishes uh his part and um we’ve already got some some good ones coming in. But, with uh further ado, why don’t we uh switch over to Alex Ledbetter, who is

[25:40] the uh founder and CEO of Delegance Brokerage. Such a great story and very relevant to um building with AI. Alex, uh I think was uh had a uh job in a commercial insurance brokerage and what struck him above all else was how little how underutilized like like zero utilization >> [laughter] >> of AI at the time and saw an opportunity to transform commercial insurance um by uh through the application of AI and

[26:11] it led him to uh down a path that uh saw him uh vibe code a Agentech uh commercial insurance brokerage uh business into existence um last year and uh launched it and um you know, single-handedly and uh as of yesterday announced uh a nice uh pre-seed funding round and is uh off and growing. So, uh very thankful to have uh Alex here today to talk about his story and uh without

[26:42] further ado, let’s let’s hear that. Thank you, Andy. No, and thank you, Connor and Ivan for doing such a great job tying all this up and uh thank you guys so much for having me. It’s it’s awesome to be back. I was on the podcast a few weeks ago, so it’s It’s great to make another appearance here at this webinar. Um like Andy was saying, I started off at a commercial insurance company in the summer of 2023. I I was actually heading into the summer before my senior year of college. I went to a liberal arts school and studied

[27:12] economics and English. Um I had never written a line of code or read a line of code um prior to March 2025. And I ended up raising about $200,000 from angel investors in February uh 2025 um to push this forward. I realized I did not have enough resources to bring in any external support, so I was going to need to get deep in the weeds and build the product out um the best I could myself. So, it wasn’t uh it wasn’t ideal. It

[27:43] was, you know, early days of of vibe coding. Um you know, back then, I don’t think, you know, it’s funny to talk about some of this stuff now, but we didn’t even have plan mode until the fall of that year. Um we didn’t even have um good context windows in any of these models um until about the summer time. So, it was a grind trying to just maintain all of context and um and push across, and that was how I stumbled across Weaviate. It became really important that the model had immediate

[28:15] access to all of the different systems and tools I was trying to use. So, Weaviate’s mCP server was critical part of of me building out um our infrastructure. This is our site. So, I’m going to take you guys through the onboarding process, and I’ll talk a little bit a little bit about how we’re using Weaviate, where we’re using Weaviate. Um and ultimately, what I found out was that leveraging this type of vector database architecture unlocks more

[28:46] sophisticated servicing capabilities than what a lot of the brokerages and insurance companies are using today. So, we’ll just go through here. Um there’s a lot of information you need to provide to insurance companies to get quotes. Um but I ultimately found out that these insurance brokerages are charging anywhere between 15 to 35% annual commissions. And with

[29:21] this underlying servicing capabilities that um WeViate helps unlock, it can reduce the cost to serve these accounts in a way that allows me to charge less for the cost of brokerage services um and help these businesses save on their insurance premiums just through reduced commissions. So, I’m just going through here. But we take all of this information and we are leveraging it to build a comprehensive

[29:53] knowledge base for every single insured. So, um uh we won’t do a website this go around. But uh once I do this OTP here, we’re about to upload our documents. Um so, a big part of of the advanced servicing capability and and building out this knowledge base is that all of these businesses have documents. They have these binders. They have these policies.

[30:24] I’m sure many of you, your companies have these 200-page policies, maybe you know, 50 to 200-page policies that nobody’s read before. There’s a lot of fine print nobody understands. And I think that’s a that is a compelling reason to leverage this type of architecture because you can get real-time answers to um all of your all of your policy-related questions. And one thing I’ll also say is uh we don’t This isn’t the only way to engage with our platform. We have uh

[30:55] servicing capabilities available over email, over We have a full SDK, we have a Slack app, an iOS app. And one of the great things about Weaviate is that with the um custom data schemas that we’re able to create, it was really easy for us to scale our memory system across different channels. So, I was able to tag portal activity versus email activity versus phone activity. And so, having kind of a unified uh memory

[31:27] system across all of the different channels that clients engage with our platform, um that was really important. So, because, you know, all of these clients have different ways that they’re used to talking to their broker. Um and so, I wanted to make whatever was minimal friction. Um and so, as you see here, some of these are already starting to come through. Effectively, what we’re doing I talked a little bit about this more in in the podcast episode. Um but effectively, what we’re doing is uh we’re converting all of these PDF pages um into images

[31:58] and leveraging multiple types of OCR. I don’t like flat OCR for um these types of documents. You end up with a lot of graphs and charts. And to Connor’s point about you know, Weaviate being able to index images and and query against images, that’s also really important for our use cases. Um so, as you see here, uh we pull out a lot of information from this policy. So, there’s a lot of different documents that we can actually classify against. So, there’s a lot of different agents um doing different things for

[32:30] each document type. So, the first one is kind of clarifying like, all right, which of these document types did they just upload because the whole goal here is I don’t want any of my clients to be experts on their commercial insurance. I don’t want them to know what all of these things are, what they have. Most of them don’t. So, I want my clients to be able to just dump in their binders. We can classify everything for them. If they know that something’s wrong, they can override it. But based on the document that we classify, um there’s certain types of structured

[33:01] data that we look for based on the classification. And we’re vectorizing everything while also building a table of contents for every single document type. So, um all of this is cooking. We pull out key information from all the policies. So, all of the sub coverages you have, the limits for each sub coverage type, the deductible for each sub coverage type. Um so, all of this gets pulled out. You guys saw it was pretty fast. Um so, trying to get people in through quickly. Um we won’t do this, but there is an

[33:32] option to go in and do a full a few additional questions, get some context about or provide some context about your portfolio, um and then get a full audit on all right, maybe you’re over covered here, there’s some optimizations here, some redundancies here. Um and so, it provides that level of analysis, but you can also jump straight into a quote request. So, we’ve got about 25 carriers that we work with today. Um and the goal

[34:03] is to make this as seamless as possible for our insured to um answer the questions they need to get quotes. So, that’s also a big part of that extraction process is we can pull out all of those details, all of the information that um you might already have in a corpus of documents. Um and so, you’re not needing to re-key information um because we’re able to leverage what we’ve extracted, what you’ve provided to help um um that information transfer between um

[34:33] between insured businesses and and carriers. I I see my job as a broker, it’s really a glorified information transfer um with some servicing capabilities baked on top. Um but we’ve built kind of a full-fledged platform, so um all don’t try to call this stuff. It It won’t work unless you have a real account. Um we we whitelist all this stuff, but you’re able to go in and and um text an AI agent, call an AI agent,

[35:04] email an AI agent. You can schedule time with me. We have all of our integrations here, so um our MCP servers are our PWA. We have an iOS app. Um I need to figure out how to put it in here. We’ve got our Slack app. Um and then we have a full SDK, so I’ve actually been working on a CLI product as well. So um I don’t know about you guys, but my experience getting commercial insurance um before this, it was kind of ridiculous. I had to go in, I would fill out a form, and

[35:35] they’d expect me to go into a 30-minute call with an underwriter, answering more questions. Um and so I wanted to make an experience where you could do all of the self-servicing capabilities, everything that you would ask your broker to do for you. Instead, you can just drive it in real time because um we have 142 customer-facing MCP tools. Um so any any piece of qualitative information that we get from an insured might trigger um an

[36:06] automated policy update, a new COI, proof of insurance, um really anything that a client might need. Um instead of having to talk to someone or wait on them, and I tell people this is so much better than the average commercial insurance broker is 60 years old. So these guys are um not always the most tech-savvy um and they’re not always the fastest. So, having something that can service you in real time built in with a memory system that, you know, is just as good as human

[36:37] photographic memory, uh it’s an easier sell to businesses that one want to save, want a better value, and just want better servicing capabilities. So, I think it raises the bar for what businesses should expect. Um this is my DocuSign rip-off. Uh um you’re able to sign broker of record agreements within our platform, um which trigger off downstream. We have a whole agency management system that I also built integrated with this. Um so, that

[37:08] gets sent off. Um the broker of record agreement will allow you to um through natural language request COIs across all of the different mediums. You can add more people to your company, um and we also have multi-entity support. So, if you have multiple entities, um you’re able to leverage we built kind of a nested knowledge base infrastructure. So, that’s another uh great use case for Weave AI is if you have um kind of complex multi-entities or or um

[37:40] requirements for nested logic, uh that’s really useful for for building out those types of parameters for different tenants. Um and then you can go in at really any time. All those documents that we just uploaded, um you can pull up, ask any questions about them. Um you know, leverage the table of contents to filter out to different things. Um we have a full conversation history, so you can filter by when queries were sent, where queries were sent. So, which medium were you using? Um we can trace

[38:10] everything back except for Open AI and Anthropic do not let us uh take the transcripts of chats. They let us take the tool calls used. Um so, that’s less good, but um the point of this is no matter where you are, um, you can you can leverage all of the same servicing capabilities and uh, I’ll just talk about this. Like, what can you do for me? This will probably list most of them. Um, but yeah, I mean, just analyzing your coverage. So, hypothetical claim

[38:40] support, identifying structured data within your within your documents. Um, and so all all of this is available for um, 36 different coverage types, um, and also bond markets as well. So, we’ve been we’ve been seeing a a lot of demand from businesses that that feel like um, this is a better value than than what’s being offered today, especially for businesses. I’ve talked to some businesses where it’s I call my broker once a year. I pay a few thousand dollars in in commercial insurance, um,

[39:12] every year and I don’t, you know, I I’m not uh, I I talk to him once a year. That’s the most expensive phone call I’m making every single year. It’s tens of thousands of dollars. So, being able to save money and and drive uh, things end to end, it’s it’s a bit more it it’s a it’s more powerful, it’s faster and um, I think that there’s a lot of businesses, especially as more businesses start leveraging agents. Like, I personally, I would never want to handle my own commercial insurance.

[39:44] I’d rather pass it off to to Claude or Open AI and and never have to think about it and, you know, leverage all of the contacts I have locally. So, that’s that’s kind of uh, how I’ve been trying to build things out. Um, we have built-in premium financing solutions as well. So, if you need financing, um, at point of sale, um, we have that as well. We can help uh, streamline the claim submission process. I don’t know how deep we want to go on all of this, but um, happy to also talk about the differences between MCP and APIs and and where MCP

[40:16] wins compared to other um, solutions. Yeah, but >> Let’s start talking about the the building of it. And this is incredibly impressive and and such a great observation. I mean, insurance and commercial insurance such a document heavy process and business and such a natural fit for AI. It’s a really about extracting information and answers out of um big insurance documents to um answer customer questions and make decisions about who to um they finally

[40:46] get your insurance with. But yeah, so let’s let’s start the Q&A a little bit. We’ll start with questions for you, Alex. We had a couple of questions about you know, why Weaviate? Why would I use Weaviate instead of PG Vector? Or why would I use it instead of other vector databases? I’ll give you a quick answer and then I’ll let Alex give you his answer since he he made that decision uh for real. And I think uh with respect to

[41:17] uh something like PG Vector, it it really comes down to the best tool for the job. You know, Weaviate was built specifically for use cases like Alex’s. You know, what you’ll find with respect to PG Vector is that number one, developer experience. You know, because Weaviate can integrate your models right into the database, it means a lot less uh code moving data, a lot less pipeline development, uh moving data between the database and and models. Uh like all vectorization, uh generation

[41:47] of embeddings can happen within the database, so it simplifies development. And then in terms of runtime and querying, as the database grows, uh you know, indexing your vector data in PG Vector is going to um become painful, painfully slow. And with Weaviate because of uh the wider variety of indexing, compression, and query options that you have, the it it’s able to scale and perform better at really any level. And we’ll share as part of the follow-up,

[42:18] I’ll share a link to a blog post that booking.com wrote just a few weeks ago explaining exactly why they switched from why they decided to centralize all of their vector applications on Weaviate moving many of them off of elastic or open search to do that including some benchmark results they did. So I’ll share that with the follow-up. And then with respect to vector databases like Pinecone, again the developer experience is usually what

[42:48] um distinguishes Weaviate from others. Also the deployment options features like multi-tenancy is kind of a native thing that Weaviate does quite well and also the deployment options if you’re talking about Pinecone specifically, they are a cloud-only service whereas Weaviate can be installed and run anywhere you’d like. But Alex, what was your you know, you had to make this decision once. What was your thought process? >> So I will say um I did have some experience like in

[43:19] between 2025 and uh when I had graduated, we were built I was working as a an AI product manager for a consulting company that was building uh custom knowledge bases. It’s funny that this was something that like a lot of the big businesses were paying for just a few years ago, but um they didn’t know how to make their own custom knowledge bases. Um so we were leveraging like the engineers came in immediately recommending Weaviate. We

[43:49] had tried to use other solutions and the setup was just way too complex and we needed something that ultimately we could pass off to this larger enterprise. So they needed something um that they could self-host uh ultimately and the fact that Weaviate um is technically, you know, open source and that that was available, we were able to build all of the infrastructure needed on our side prior to handing it off to this larger

[44:20] client. So, that was really important. At the time, I think this is still probably the case, but we had looked at like it was technically possible. I think it still is, but and maybe it’s gotten a little easier, but we had looked at RDS as a solution with an AWS and it was a nightmare getting all of the metadata tagging lined up how we needed it to be. So, something like Weaviate is just I mean, for me a lot of this stuff is how quickly can you go? How easy is it to set up? Can your agent set it up for

[44:51] you? And Weaviate can do all could do all of those things before a lot of the competitors and and they’ve stayed really far on the on the cutting edge, I would say in terms of like, you know, the query agents. There’s There’s not a lot of platforms with with built-in querying out of the box, especially to this level of quality. So, and I I think I know I had a dedicated account executive, which was really important for me at the time. Like, I don’t even

[45:23] get account executives for my bank right now. So, having that kind of hands-on technical support as a Vibe Coder was really important to me as well. There were times when like my account executive was able to provide me with resources, with documentation for different problems I was running into, and I was able to just inject that context straight into my agent to help me resolve those issues. So, I was able to get good quality of like level of support from Weaviate as well.

[45:55] I’m not sure other companies are are providing those types of resources or support um to all of their clients. So, that’s just my experience and there’s a lot of other technical things as well. I put something in the chat about this as well, but the schema flexibility is also really important. When you have a lot of these out-of-the-box tools that are really simple, it can actually be somewhat limiting because of how templated they are. Like, I never entertained N8N for

[46:25] that reason. It’s Yeah, like I I think it’s important that you have this flexibility to This is my two cents. >> Thank you. Let’s see another question here for Yvonne. The The MCP servers Can you talk a little bit about the availability of of those? >> Of course. If it’s about the open-source question, then um the Weaviate database MCP server is of course open source, so it’s part of the

[46:56] database itself. If you spin up your own cluster or even if you use the Weaviate Cloud, you have it by default. So, no setting up, no kind of fees or something like that. The query agent is a separate service that we offer. At Weaviate as part of Weaviate Cloud, you do have a free number of requests, queries that you can send to the query agent, but that one is not open source. It’s a managed service.

[47:26] >> And I think another question is it uh are you able to connect to it from Cloud Desktop? >> Yes, of course. You can also configure it through I’m not sure where settings preferences in the Cloud Desktop app. I have tried it out myself. And it should work the same way as with Cloud Code. >> Great. And question for you, Connor. I think you answered this in um in the box, but just for the recording. Uh somebody wanted to know more about

[47:56] the evaluation outputs for final answer is partial answer missing information sources. >> Oh, yeah, awesome. >> Clarify the question and and answer it. Yeah. >> Oh, yeah, cool. So, yeah, having grounded generation and making sure that your responses aren’t being hallucinated, they’re actually based on the data in your database is one of our core focuses with the query agent and the way we solve this so far is you have an optional argument that’s on the result evaluation. You can turn it off

[48:28] if you don’t want to spend the extra inference cost for this, but when it’s enabled, what we do is from the final answer, we apply another LLM inference that we’ve tuned and optimized to assess that final answer with the retrieved context, evaluate, and populate fields like if it’s a partial answer, if it’s missing information, and then just validate the sources that it’s returning in that structured response attribute. So, those are some of the things that we’re doing towards fighting hallucinations and making sure this is a really reliable retrieval augmented generation API. And

[48:58] I and we’d love to work with you. If you have you know, if you have if you’re not finding it if there’s any particular additions you want there, any tests you have, please contact us. We’d love to see how we can help further. >> Great, thanks. Alex, question about your stack. Like what is your What else is in your vibe your uh AI coding stack besides Weaviate and the gazillion MCP servers here? >> Yeah, I’d say I’m always looking to optimize. Like even now, I

[49:30] um I basic I found out 2 weeks ago after our podcast, Connor, that one thing I was describing to you, there’s actually like a technical term for it. Like coming from a non-technical background, um I’ve realized a lot of the stuff that I’ve created or just kind of intuited as something I would need or would want um got kind of just like first principles building. A lot of it already exists or has like technical names behind it or so I’ve I’ve been kind of like rediscovering things and

[50:02] I I want to talk about our software factory that I built. So something I mentioned this in the in the comments but when I was vibe coding I was spending seven I spent seven to eight months building before I had the first company come on to my platform. I went through my own user experience flow over 700 times and so a lot of that iteration it was critical that I was using tools or infrastructure that I could control or

[50:33] feed context easily into my agents via terminal. I was building last year I did everything in cursor. I was a top 5% cursor user last year but I switched over to Claude code in the new year I think like a lot of other people. Um So oh I just got to ask is my platform agentic first? Yes, we are. I I integrated web MCP. So I did want to mention that as well. Web MCP we’ve got I know that there’s a lot of strong thoughts about MCP versus

[51:04] API versus CLI. One thing that I know for certain web MCP is critical infrastructure to have if you want things to be agent first. It makes it so browser agents that visit your platform or visit your site are able to use all of the functionality easier than if you had them just doing like a screenshot loop with you know uh just continuously trying to find the right fields within a form or or find the right functionality within your

[51:35] page. Web MCP is great for that. So I that’s how I’ve been trying to build. I think we’re heading toward a world I was reading where by 2030 we should be seeing three to five trillion of payments processed through a gen tech commerce. So, I’m anticipating a world I think personal agents obviously a lot of movement there over the past few weeks, but I bet within the next few years, we’re going to see business adoption and enterprise adoption trailing soon and

[52:08] there’s a lot of back office operations or administrative work that people would rather leverage agents for and agents are already pretty good at at you know, especially multi-agent architectures. I think you can reduce the risk of hallucinations or things going wrong if you have multiple agents that are looking at outputs and kind of collaborating together. It It makes it harder to prompt inject. It makes it harder for outputs to look bad and right

[52:40] now costs are going down. So, I think long-term there’s going to be a lot of multi-agent architecture. Like the way I see it, I see it as like a test and you have two students that both average like an 80% on a test. You know, we’ll we’ll keep it conservative. So, like OpenAI and and Claude or Anthropic, they’re both 80% level students and they take a test together. Together, there’s not one that went over lap. So, they actually

[53:12] score higher on the test when they work together. So, I’ve been I see someone someone’s talking in the chat a lot to me also. But yeah, I I Superbase was great. AWS was great. The CLI for AWS was great. Superbase, that was really useful. Um I have my [snorts] my task definitions are exploding with different tools that I’m using. Um But those are probably like the the

[53:43] core ones. I think, you know, Weaviate AWS and Superbase was another platform I used. But, if I were to do it again, I didn’t realize that you could use Weaviate for structured data. Connor and I talked a little bit about that as well. If I were to do it again, I would simplify and I would I would use Weaviate for structured data and unstructured data. And that would be even better because they’re in the same systems and it’s easier to retrieve and keep in context. One one less tool call that could go

[54:14] wrong, one less query that could go wrong, one less dependency. >> Cool. All right, we’re at the top of the hour. I want to thank Connor, Yvan, Alex for taking time out today. Really enjoyed the information. Hopefully, everybody in the audience did too. We will follow up with a link to the recording of this event for anybody who missed any of it. Also, link to some other resources like the the podcast interview between Connor and Alex where

[54:44] Alex goes into more detail on the the building of Delegates and I’ll share the the link to the booking.com blog post blog post where they talk about sort of standardizing on on Weaviate for their AI applications. And with that, we hope to see you again at a at event in the future. Thanks very much for attending today, everybody. Bye-bye. >> Thanks, everyone. >> Bye. >> Thanks, everyone.