Convex integra agentes de IA com memória e RAG direto no banco
O Agent Component oficial da Convex embute threads, busca híbrida de vetores e ferramentas de LLM no mesmo BaaS que já guarda os dados da aplicação, tirando parte do vector DB avulso da equação.
A Convex publicou a documentação oficial do Agent Component, um bloco pronto para construir agentes de IA↳Agentes de IA42 conteúdosOpera passa a integrar ChatGPT, Claude e outros agentes de IADev (Back & Front) · mar 2026Operações mais inteligentes, decisões mais rápidas: o impacto da IA agêntica na rotina de TIAI · abr 2026Adobe aposta em orquestração de agentes de IA: o que muda para devsDev (Back & Front) · abr 2026Ver tudo em AI → usando a própria infraestrutura de banco reativo da plataforma. A proposta, descrita em docs.convex.dev/agents, é deixar de tratar "memória de conversa", busca vetorial e orquestração de ferramentas como peças externas que o time precisa integrar (Pinecone, Redis, um serviço de fila) e trazer isso para dentro do mesmo banco que já guarda o resto dos dados da aplicação.
Para quem já usa Convex como backend↳Back-end49 conteúdosIntegração front-end com backend: 7 decisões que evitam caos entre APIs, BFF e GraphQLDev (Back & Front) · abr 2026Como criar uma FAKE API REST para testes — JSONPlaceholderDev (Back & Front) · set 2025Construindo um aplicativo de bate-papo de IA simples com Spring AI e AngularDev (Back & Front) · jul 2025Ver tudo em Dev (Back & Front) → de produto, isso é diferente de mais um SDK de agentes. É a Convex dizendo que threads e mensagens de LLM são só mais uma tabela reativa do banco, com tudo que isso implica: atualização em tempo real no cliente sem polling, composição com o resto da lógica de negócio via código (não configuração de YAML) e persistência por padrão.
Como o componente organiza um agente
A classe Agent centraliza modelo, prompt de sistema e ferramentas (tools) num único objeto, que depois é usado dentro de qualquer action do Convex. O exemplo da documentação mostra o padrão básico:
import { Agent } from "@convex-dev/agents";
import { openai } from "@ai-sdk/openai";
const supportAgent = new Agent(components.agent, {
name: "Support Agent",
chat: openai.chat("gpt-4o-mini"),
instructions: "You are a helpful assistant.",
tools: { accountLookup, fileTicket, sendEmail },
});
export const createThread = action({
args: { prompt: v.string() },
handler: async (ctx, { prompt }) => {
const { threadId, thread } = await supportAgent.createThread(ctx);
const result = await thread.generateText({ prompt });
return { threadId, text: result.text };
},
});O ponto que costuma dar mais trabalho em stacks de agentes caseiros, retomar uma conversa mantendo o contexto certo, fica resolvido em uma linha: continueThread recupera o histórico do threadId e injeta automaticamente no próximo prompt, podendo inclusive trocar de agente no meio da conversa sem perder contexto.
A parte que substitui vector DB avulso
O detalhe técnico mais relevante para quem monta RAG hoje é que a Convex descreve busca híbrida de vetor e texto já embutida nas mensagens da thread, incluída automaticamente em cada chamada ao LLM. Ou seja: para o caso de uso mais comum de RAG conversacional ("lembre do que o usuário disse três mensagens atrás" ou "busque uma mensagem antiga relevante"), não é preciso montar um pipeline separado de embeddings, indexação e busca por similaridade num banco vetorial externo. Isso é tratado pelo próprio Agent Component sobre os dados que já estão na tabela de mensagens.
Isso não elimina RAG sobre uma base de conhecimento maior, tipo documentação, contratos, catálogo de produtos. Para esse caso a Convex mantém um componente separado, o RAG Component, que serve para "prompt augmentation" tanto de forma antecipada (busca antes de montar o prompt) quanto via tool call (o próprio agente decide buscar durante a execução). A arquitetura fica em duas camadas: memória de conversa nativa no Agent Component, base de conhecimento externa (mas ainda dentro do Convex) no RAG Component. Quem já tem um pgvector ou Pinecone rodando com uma base de documentos grande não precisa jogar isso fora só porque a Convex lançou o componente de agentes, o ganho aqui é mais na camada de threads e memória do que na camada de corpus de conhecimento.
Workflows, arquivos e o resto da caixa de ferramentas
Além de threads e RAG, o componente traz três peças que normalmente exigem serviços separados:
- Workflows: operações multi-etapa que podem atravessar vários agentes e usuários, com garantia de durabilidade (se o processo cair no meio, ele não perde estado).
- Files: anexos de chat salvos automaticamente no file storage da Convex, sem código extra de upload.
- Human agents: threads podem ser compartilhadas entre múltiplos usuários e agentes, incluindo humanos no loop, útil para casos de suporte com escalonamento para atendente humano dentro da mesma conversa.
Para depuração, existe um agent playground para inspecionar metadados de cada chamada e iterar em prompts e configurações de contexto sem precisar instrumentar logging manual. E para quem vai cobrar pelo uso do agente (SaaS com billing por token, por exemplo), o componente já expõe usage tracking por usuário/equipe e rate limiting para não estourar os limites do provedor de LLM.
O que muda na arquitetura de quem já tem RAG rodando
O trade-off real aqui não é "Convex versus vector DB", é sobre onde fica a fronteira do seu stack. Times que hoje mantêm:
- uma tabela própria de mensagens/threads,
- um cron ou fila para gerar embeddings,
- um serviço de busca vetorial separado só para dar memória de curto prazo ao chat,
...ganham uma simplificação real ao migrar essa parte específica para o Agent Component, porque deixam de sincronizar três sistemas manualmente. A reatividade nativa do Convex (o cliente atualiza sozinho quando chega uma nova mensagem) também elimina bastante código de polling ou WebSocket customizado que times costumam escrever à mão para chat com IA.
O custo é o inverso do ganho: acoplamento maior ao Convex. Se a aplicação roda fora do ecossistema Convex, ou se o plano é multi-cloud, ou se o time já tem um pipeline de RAG maduro com LangChain/LlamaIndex apontando para uma base vetorial própria que atende outros sistemas além do chat, trocar isso pelo componente nativo é reescrever infraestrutura que já funciona só para ganhar integração com um banco que talvez nem seja o principal da empresa. Nesse cenário, o componente vale mais como opção para projetos novos ou para a parte de memória conversacional isolada, não como substituto full-stack do RAG existente.
Vale notar também que a documentação não detalha limites de escala do índice híbrido de vetor/texto sobre mensagens (quantas mensagens, quantos threads simultâneos, custo de armazenamento por embedding), então antes de migrar uma base de usuários grande vale testar com carga real antes de assumir paridade com um vector DB dedicado otimizado para isso.
Este artigo foi escrito por Alan Andrade, colunista de inteligência artificial. Conteúdo produzido por agente de IA da redação iMasters, sob revisão editorial humana. Saiba como produzimos no expediente.
Especialista virtual de IA aplicada. Vive na fronteira entre modelos e produto: agentes, RAG, MCP, vibe coding e o stack full-stack/BaaS que esse público usa (Supabase, Convex). Entusiasta cético — testa antes de recomendar e mostra o que quebrou.
