MCP para Storefronts Autônomos: Construindo Loops de Agentes Auto-Curadores
Em 2 de abril, Guilherme Rodrigues apresentou MCP para Storefronts Autônomos: Construindo Loops de Agentes Auto-Curadores no MCP Dev Summit North America em Nova York. A sessão cobriu como estamos usando MCP para construir storefronts que detectam seus próprios problemas, os consertam e melhoram sua própria performance, com exemplos de stores em produção.
Storefronts de alto volume sempre estão sangrando
Imagens quebradas, picos de latência, crawlers martelando filtros de busca, scripts de terceiros degradando performance. Sempre há mais problemas do que qualquer time humano consegue acompanhar, e cada minuto de downtime custa receita real. Estamos rodando centenas de storefronts enterprise há três anos, e o padrão é consistente: a área de superfície de coisas que podem dar errado cresce mais rápido do que o time que cuida dela.
Estamos trabalhando em uma abordagem diferente: storefronts que detectam seus próprios problemas, os consertam e melhoram sua própria performance ao longo do tempo. Este artigo percorre os cinco passos que seguimos para chegar lá, de centralizar ferramentas em servidores MCP até deixar agentes especializados colaborarem via git.
A mudança de permitir para fazer
Soren Larson colocou bem em You Must Just Do Things: a camada de aplicação de IA ainda está na maioria construindo ferramentas que ajudam humanos a fazer coisas mais rápido. O verdadeiro shift de valor é em direção a software que pode possuir resultados, software que faz o trabalho em vez de permitir que outra pessoa o faça.
“A camada de app B2B AI está presa em 'permitir' em um mundo que realmente preza 'fazer'.”
Essa distinção importa. Não estamos construindo dashboards que ajudam engenheiros a encontrar problemas mais rápido. Estamos construindo sistemas que encontram problemas e os consertam. O estado final é um storefront que se corrige quando algo quebra e se melhora quando há uma oportunidade, com humanos envolvidos apenas onde julgamento é necessário.
Cinco passos para storefronts autônomos
Chegar à autonomia é uma progressão. Cada passo se baseia no anterior, e você não pode pular direto para o final sem dominar cada um primeiro.
Centralizar ferramentas com MCP
Adicionar conhecimento de domínio como skills
Usar agentes sob demanda
Adicionar triggers
Deixar agentes colaborarem
Centralizando ferramentas e conhecimento
Passo 0: Transformar APIs em servidores MCP
A fundação: todo sistema que seu time depende se torna um servidor MCP. Para nós, isso começou com VTEX, a plataforma de e-commerce que a maioria de nossos clientes brasileiros usam. VTEX publica OpenAPI specs para todos os 68 de seus domínios de API. Escrevemos um pipeline que lê essas specs e gera tools MCP automaticamente. 710 tools, um dia de trabalho, cobrindo catálogo, orders, pricing, logistics, payments e tudo mais. Quando VTEX adiciona uma nova API, o pipeline a pega na próxima execução.
Além da VTEX, conectamos ClickHouse para analytics, GitHub para código e HyperDX para monitoramento de erros. Nosso gateway MCP centraliza todos esses atrás de um protocolo único com autenticação e governança consistentes.
Passo 1: Ensinar agentes o que procurar
O Passo 1 se revelou tão importante quanto o Passo 0. Dar a um agente acesso à sua API de monitoramento não é suficiente se ele não entende seus tipos de erros, seus formatos de log ou o que um storefront saudável parece na sua infraestrutura. Codificamos três anos de experiência em otimização de storefront em um repositório de storefront skills: padrões, heurísticas e conhecimento de domínio que agentes podem referenciar junto com as ferramentas.
Um agente com acesso a uma API de monitoramento de erros mas sem conhecimento de quais erros importam vai surfar tudo. A camada de skills diz aos agentes o que procurar, o que é normal e o que requer ação. Não é só sobre dar acesso a uma API. Seus dados têm formatos e semânticas que você precisa ensinar aos agentes também.
Quando agentes veem o que dashboards perdem
Passo 2: Agentes sob demanda
O primeiro grande resultado veio da loja brasileira da Fila. O site estava experimentando alta latência em todas as páginas. O time conseguia ver nos dashboards mas não conseguia identificar a causa. Demos a um agente acesso a dados de eventos da CDN e logs de erro, e ele encontrou a resposta em uma única passada: um bot de crawling estava fazendo uma explosão de filtros em páginas de listagem de produtos, combinando cada filtro disponível em um loop e gerando quantidades massivas de tráfego inútil. O padrão estava distribuído em dois sistemas diferentes de monitoramento. Nenhum dashboard tinha sido desenhado para surfá-lo.
O bot tinha queimado 4.5 TB de bandwidth em 15 dias e desabou a taxa de cache hit de 41% para 13.7%. O padrão estava escondido em métricas de CDN, WAF e origin. Nenhum dashboard único o surfou. O fix, atualizando robots.txt e regras de bloqueio de CDN, reduziu bandwidth 97% da noite para o dia. O ponto mais amplo: dashboards respondem perguntas que você pensou em fazer antecipadamente. Agentes podem surfar padrões que você não sabia procurar.
“Eu costumava filtrar dashboards Cloudflare manualmente. Agora conecto ClickHouse e Cloudflare e o agente analisa para mim, sugere quais regras aplicar.”
De sob demanda para sempre-on
Passo 3: Triggers e agentes agendados
Passos 0 a 2 são sobre humanos usando agentes quando precisam. O Passo 3 remove o trigger humano. Construímos um agente de saúde de sistema que monitora dados de CDN e error logs a cada dois minutos, por cliente. Quando detecta um pico de latência ou anomalia de taxa de erro, posta um relatório para Discord e cria uma issue Linear com sua análise. Nenhum humano tem que estar monitorando um dashboard.
Agentes sob demanda (Passos 0-2)
- Humano decide quando pedir ajuda
- Engenheiro tem que notar um problema primeiro
- Cobertura limitada a horário de trabalho e atenção
- Reativo: problema → investigar → consertar
Agentes com triggers (Passos 3-4)
- Agente monitora continuamente em schedule
- Anomalias detectadas em minutos
- Cobertura 24/7 em todos os sites de clientes
- Proativo: detectar → diagnosticar → propor fix
Passo 4: Agentes que colaboram
O passo final é deixar agentes trabalharem juntos. O agente de saúde de sistema posta uma issue no GitHub com seu diagnóstico. Um agente developer pega a issue e propõe uma PR. Agora, um humano ainda revisa e faz merge. Conforme a verificação melhora, o objetivo é que esse loop se feche por si só para fixes verificáveis.
É fácil se frustrar quando agentes não resolvem uma solução de primeira. O que estamos vendo é que é muito mais sobre criar agentes pequenos que fazem bem uma parte do trabalho e depois ajudá-los a colaborar.
Além de curação: melhorando conversão
A mesma abordagem que conserta problemas também pode melhorar resultados. Estamos trabalhando nisso com a Farm, uma das maiores varejistas de moda feminina do Brasil. Suas páginas de listagem de produtos têm centenas de produtos, e currar manualmente a ordem de cada coleção em escala não é viável. Dados de conversão mostravam que produtos de alto desempenho estavam enterrados onde shoppers nunca scrollam.
Construímos um agente que analisa dados de conversão e reordena coleções de produtos diariamente. O agente roda um modelo de machine learning, conversa com o MCP da VTEX para atualizar ordenação de produtos e opera autonomamente em um schedule.
Mas automação sozinha não é suficiente para trabalho sensível a marca. Times de marketing querem participar de decisões de merchandising. É aqui que MCP Apps entram: servidores MCP podem expor UIs completas junto com suas ferramentas, então stakeholders humanos podem revisar, ajustar e aprovar o que os agentes propõem. O agente cuida da análise. O humano fornece o julgamento.
Quando agentes deveriam ser autônomos?
Um framework útil para decidir onde desenhar a linha vem de Services: The New Software da Sequoia, que separa trabalho em duas dimensões: inteligência e julgamento.
Inteligência
- Complexo mas baseado em regras: coding, debugging, monitoramento, análise de dados
- Output pode ser verificado com critérios claros
- Autopilot: venda o trabalho, entregue o resultado diretamente
Julgamento
- Requer experiência, gosto e instinto: marca, estratégia, fit cultural
- Pessoas razoáveis discordariam sobre a resposta correta
- Copilot: venda a ferramenta, humano retém autoridade de decisão
A pergunta prática não é se automatizar. É quanto de autonomia cada tarefa merece. Tarefas verificáveis ganham autopilot completo. Tarefas que dependem de julgamento ganham uma interface para revisão humana. Construir o limite certo entre esses dois é o desafio de design central.
O objetivo não é acertar na primeira tentativa. O objetivo é aprender quais rails estão faltando para que agentes possam ser mais e mais autônomos. Qual rail está faltando? Essa é a pergunta fundamental.
Pontos-chave
MCP como infraestrutura
Um protocolo para ferramentas, apps e governança. Os mesmos servidores MCP que agentes usam também servem interfaces humanas. Construa uma vez, sirva ambos.
Autonomia é uma progressão
Centralize ferramentas. Adicione conhecimento de domínio. Use agentes sob demanda. Adicione triggers. Deixe agentes colaborarem. Cada passo se baseia no último. Pular à frente não funciona.
Inteligência vs julgamento
Tarefas verificáveis ganham autopilot. Tarefas que requerem gosto ou senso de marca ganham interfaces human-in-the-loop. O limite entre os dois é onde o trabalho de design vive.
Repos open-source que usamos para isso:
- storefront-skills: conhecimento de domínio para agentes de e-commerce
- mcps: servidores MCP open-source (HyperDX, ClickHouse e mais)
- deco Studio: gateway MCP e control plane
Veja esses agentes ao vivo na VTEX Day 2026
Tudo descrito aqui está rodando em produção. Estamos mostrando demos ao vivo de storefronts se auto-curando, ranking autônomo de produtos e toda a infraestrutura MCP por trás disso. Venha conversar conosco sobre seu caso de uso.
