A stack de tecnologia do Claude Code para um site agêntico

Resposta rápida: Um site agêntico é um site de marketing que agentes de IA ajudam a construir, operar e melhorar, enquanto pessoas aprovam as mudanças que importam. A stack ideal para ele mantém tudo o que o agente toca em arquivos que ele consegue ler: um framework de sites estáticos como o Astro, um CMS headless com os schemas no código, como o Sanity, uma hospedagem com deploy previews e funções agendadas, como a Netlify, e o Claude Code trabalhando por meio de pull requests.

A maioria das equipes de SaaS B2B já usa IA para escrever textos. Muito poucas deixam um agente alterar o próprio site, e as que tentam costumam descobrir o motivo do pior jeito: uma plataforma feita para clicar em um editor visual não dá ao agente nada para ler, nada para testar e nenhum lugar seguro para experimentar. A solução é uma stack e um conjunto de regras pensados para o agente desde o início.

Este guia apresenta essa stack, as proteções que mantêm um site no ar em segurança e os fluxos de trabalho de agentes que rodam nela. Ele foi escrito a partir da reconstrução do saas-hackers.com, que roda em Astro, Tailwind, Sanity e Netlify e foi construído com o Claude Code. Se você ainda está definindo o que o seu site precisa fazer, comece pelo nosso guia de estratégia de site para SaaS B2B e volte aqui para a construção.

O que é um site agêntico?

Um site agêntico é um site em que agentes de IA fazem boa parte da construção e da manutenção, dentro de regras definidas por pessoas e de verificações que rodam a cada mudança. Os agentes escrevem páginas, corrigem links, atualizam conteúdo e abrem alterações de código. As pessoas decidem para que o site serve, aprovam tudo o que for arriscado e conferem os resultados.

Isso é diferente de um construtor de sites com IA, que gera um site uma única vez a partir de um prompt. Em um site agêntico, o agente continua trabalhando depois do lançamento, como faria um desenvolvedor ou um editor de conteúdo, e toda mudança que ele faz passa pela mesma revisão que a de uma pessoa.

Três coisas tornam um site agêntico, e não apenas assistido por IA:

• O agente consegue ler tudo o que define o site. Templates de página, tipos de conteúdo, design tokens, redirecionamentos e as próprias regras ficam em um repositório de código, e não apenas em um painel.
• Toda mudança pode ser testada antes de ir ao ar, com um build que falha diante de uma página quebrada, um link de preview para cada alteração e um teste simulado (dry run) para cada script de conteúdo.
• As pessoas ficam com as chaves que importam. Fazer o merge do código, publicar conteúdo sensível e qualquer coisa que gere custo continuam com uma pessoa responsável.

Por que a stack importa ainda mais quando agentes fazem o trabalho?

A stack importa mais porque um agente só trabalha com segurança com aquilo que consegue ver e verificar. Uma pessoa percebe que uma página está estranha em um editor visual. Um agente precisa que esse conhecimento esteja registrado: como um schema que rejeita um campo ausente, uma verificação que derruba o build ou uma regra em um arquivo que ele lê antes de cada sessão.

Uma stack feita para agentes tem quatro propriedades:

1. Texto em vez de cliques. Configuração, modelos de conteúdo e estilos são arquivos no repositório, para que o agente possa lê-los, alterá-los e explicá-los.
2. Feedback rápido e honesto. Um build ou teste que falha de forma explícita avisa o agente que ele errou antes que um visitante perceba.
3. Um lugar seguro para testar. Branches, rascunhos e links de preview permitem que o agente mostre o que fez sem tocar no site no ar.
4. Um único ponto de revisão. Toda alteração de código chega como um pull request que uma pessoa pode ler e aprovar ou rejeitar.

Com isso em vigor, a escolha do modelo importa menos. Sem isso, até um agente cuidadoso vai acabar quebrando alguma coisa, porque nada avisa que isso aconteceu.

Qual é a stack de tecnologia do Claude Code para um site agêntico?

A stack tem cinco camadas: um framework de sites estáticos, um CMS headless, uma hospedagem, o agente e o ponto de revisão entre elas. Cada camada existe porque dá ao agente algo para ler ou algo para verificar.

Um framework de sites estáticos: Astro

O Astro gera as páginas com antecedência. Por padrão, ele pré-renderiza todas as páginas, rotas e endpoints como HTML estático no momento do build, e você pode optar por renderizar rotas específicas sob demanda quando for preciso (Astro, 2026). Para um agente, a saída estática é uma dádiva: o site inteiro existe como arquivos depois do build, então um script pode verificar cada página antes de qualquer coisa ir ao ar.

O SaaS Hackers renderiza todas as páginas de forma estática. A única página renderizada sob requisição é a prévia de rascunho, que os editores abrem a partir do CMS para ver mudanças não publicadas. Todo o resto é verificado no momento do build, e o conteúdo já está no HTML no primeiro carregamento, inclusive cada item de uma lista filtrada.

Um CMS headless com schemas no código: Sanity

Um CMS headless mantém o conteúdo separado do design do site e o entrega ao site por meio de uma API. O que importa para os agentes é onde fica o modelo de conteúdo. No Sanity, um schema descreve os tipos de documentos e campos que os editores podem criar, e ele é definido em código na configuração do Studio (Sanity, 2026).

Como os schemas são código, um agente pode ler exatamente de que é feito um post de blog ou um perfil, adicionar um campo por meio de um pull request e gravar conteúdo por scripts que o schema valida. Os editores continuam tendo um editor visual. O SaaS Hackers mantém todos os schemas no repositório, e nunca apenas no painel, o que é uma das regras do arquivo do projeto.

Uma hospedagem com previews e funções: Netlify

A hospedagem dá ao agente duas coisas: um preview de cada mudança e um lugar para rodar pequenas tarefas. A Netlify gera um deploy preview automaticamente quando um pull request é aberto em um repositório conectado, em um endereço próprio, e adiciona a ele um cabeçalho noindex para que os buscadores o ignorem (Netlify, 2026). Esse link de preview é como uma pessoa confere a mudança de um agente em uma página real antes do merge.

As funções agendadas da Netlify rodam como um cron job em horários fixos em UTC, apenas no deploy de produção publicado, com limite de 30 segundos por execução (Netlify, 2026). Tarefas curtas e agendadas combinam bem com a manutenção agêntica: verificar se algo mudou e, então, decidir se é preciso fazer um novo build.

Claude Code: CLAUDE.md, skills, hooks e MCP

O Claude Code é o agente. Quatro de seus recursos transformam um modelo capaz em um integrante confiável da equipe:

• CLAUDE.md. Os arquivos CLAUDE.md são arquivos Markdown que dão ao Claude instruções permanentes para um projeto, e o Claude os lê no início de cada sessão (Anthropic, 2026). Compartilhado por controle de versão, o arquivo do projeto reúne os comandos de build, os padrões e as regras que todos seguem.
• Skills. Uma skill é um SKILL.md arquivo de instruções que o Claude adiciona ao seu conjunto de ferramentas e usa quando é relevante. Ao contrário do CLAUDE.md, o conteúdo de uma skill só é carregado quando ela é usada, então procedimentos longos quase não custam nada até serem necessários (Anthropic, 2026). Nosso texto explicativo sobre Claude Skills para equipes de marketing mostra como elas funcionam na criação de textos.
• Hooks. Hooks são comandos de shell que o Claude Code executa em momentos definidos, o que dá um controle determinístico: certas ações sempre acontecem, sem depender de o modelo escolher fazê-las (Anthropic, 2026). Use-os para regras que nunca podem ser flexibilizadas, como bloquear edições em um arquivo de segredos.
• Servidores MCP. O Model Context Protocol é um padrão de código aberto para conectar ferramentas de IA a outros sistemas, e os servidores MCP dão ao Claude Code acesso às suas ferramentas, bancos de dados e APIs (Anthropic, 2026). É assim que um agente lê dados de analytics, rankings ou um CMS diretamente, em vez de trabalhar com o que você cola. Nosso guia sobre agentes de marketing com IA e MCP apresenta as ferramentas de marketing que você pode conectar.

Sessões na nuvem e tarefas agendadas

Uma sessão na nuvem é uma sessão do Claude Code que roda em infraestrutura de nuvem, e não no seu notebook, e continua rodando depois que você fecha a tampa (Anthropic, 2026). Execuções agendadas e disparadas por gatilhos começam, cada uma, como uma sessão na nuvem. É isso que permite a um agente publicar um post às 01:43 ou medir rankings numa manhã de terça-feira sem ninguém ao teclado.

Pull requests do GitHub como ponto de revisão

Toda alteração de código feita por um agente vai para uma branch e chega como pull request. O preview de deploy é gerado a partir dela, as verificações rodam nela, e uma pessoa faz o merge ou não. No SaaS Hackers a regra é simples: os agentes abrem pull requests, e o Darren faz o merge. Nenhum agente faz merge do próprio trabalho.

Como evitar que um agente quebre um site no ar?

Você impede que um agente quebre um site no ar tornando o caminho seguro o único caminho: um backup antes de qualquer gravação, um dry run que mostra a alteração, verificações em cada build e limites para o que ele pode alterar sozinho. Nada disso depende de o agente se lembrar de ter cuidado. Tudo está escrito em scripts, schemas e no build.

Backup, dry run e só então gravação

Todo script que altera conteúdo publicado no SaaS Hackers funciona da mesma forma:

1. Backup. npm run backup exporta o conjunto de dados inteiro para um arquivo com data antes de qualquer alteração.
2. Dry run. O script roda sem --write, verifica tudo e escreve um relatório do que mudaria.
3. Leitura do dry run. O agente, ou uma pessoa, lê esse relatório antes de seguir adiante.
4. Gravação. Só então o mesmo script roda com --write.
5. Verificação. O site é gerado a partir do conteúdo publicado e as verificações de rotas e de schema são executadas.

O relatório de entrega após cada tarefa informa qual backup foi feito, para que qualquer alteração possa ser desfeita.

Bloqueios no CMS

Alguns erros são mais baratos de evitar no CMS do que de corrigir depois. No Studio do SaaS Hackers, o slug fica bloqueado assim que o documento é publicado, então um endereço no ar não muda por acidente. Uma página não pode ser publicada em um endereço que tenha um redirecionamento ativo, e novas imagens não podem ser publicadas sem texto alternativo. Os scripts despublicam em vez de excluir e deixam em paz os rascunhos de outras pessoas.

Verificações em cada build

O build é o crítico mais honesto do agente. No SaaS Hackers, o build npm run build é interrompido se qualquer uma destas verificações falhar:

• design tokens desatualizados, cores ou tamanhos usados fora dos tokens, ou texto sem contraste suficiente;
• um bloco de seção do CMS sem o componente de página correspondente;
• dados estruturados que não são interpretados ou que não têm o schema do tipo de página, ou uma página sem exatamente um H1;
• links de idioma (hreflang) que não apontam nos dois sentidos.

Depois de um build, a verificação de rotas confirma que todo endereço no ar dentro do escopo retorna 200, e a verificação de paridade compara títulos, descrições, canonicals, títulos de seção e schema com o site no ar. A velocidade também faz parte das verificações: nosso verbete do manual sobre Core Web Vitals explica as métricas que vale acompanhar.

Segredos ficam fora do repositório

Tokens e chaves ficam em um arquivo local .env que o git ignora, e nas variáveis de ambiente do host. O repositório guarda apenas uma lista com os nomes delas. Um agente pode usar uma chave que está no ambiente sem nunca gravá-la em um arquivo, em um commit ou em um relatório.

Limites para o que um agente pode alterar sozinho

Decida com antecedência o que um agente pode fazer sem pedir autorização, escreva isso e aplique em código sempre que possível. É assim que o SaaS Hackers divide isso hoje:

• Posts do blog são publicados imediatamente, depois que as verificações do script passam, e uma pessoa os revisa depois.
• Textos de páginas, títulos e links internos mudam por meio do agente de SEO, dentro de limites fixos por execução.
• Alterações de código vão para um pull request que uma pessoa aprova com merge.
• Solicitações de perfil de agências aguardam uma pessoa tocar em Approve no Slack.
• Notas, avaliações e rankings nunca são alterados por um agente nem a pedido.

Limites de custo

Agentes podem gastar dinheiro rápido, então o custo também é uma proteção. O SaaS Hackers já refez o build a cada publicação, e cada deploy em produção custa 15 créditos da Netlify. Agora os rebuilds são limitados a um por dia: uma função agendada roda às 05:17 UTC e só refaz o build se algo tiver sido publicado desde o build que está no ar. O briefing do agente de SEO também diz para nunca disparar um deploy por conta própria.

Quais fluxos de trabalho de agentes rodam em um site agêntico?

Com a stack e as proteções no lugar, os agentes podem assumir o trabalho repetitivo que costuma ficar para trás: publicar, medir, atualizar e traduzir. Cada fluxo de trabalho tem um briefing escrito, uma programação, limites e um relatório.

Publicação de um post no blog a cada dois dias

Uma tarefa agendada escreve e publica um post do backlog de conteúdo a cada dois dias, às 01:43 UTC, antes do rebuild diário. Ela escreve com uma skill de copywriting e confere o texto com uma skill de auditoria de conteúdo. Depois, um script de publicação recusa o post se encontrar travessão, placeholder, slug errado, meta description longa demais, menos de três links internos ou qualquer link interno que não esteja no ar. Ela só cria posts novos e nunca altera um existente.

Um agente de SEO que mede e age duas vezes por semana

Às terças e sextas, às 06:41 UTC, uma sessão nova mede os rankings, avalia o site em relação às metas e percorre uma lista priorizada de ações. Cada execução pode alterar no máximo 8 páginas, criar 1 nova lista e adicionar 30 links internos, com limites para chamadas de dados pagos e gastos com tradução. Ela registra cada alteração com uma cópia do texto anterior para poder desfazê-la, envia as alterações de código para pull requests e reporta no canal de Slack da equipe. Nossa comparação entre Claude Code e AirOps para equipes de conteúdo mostra quando esse tipo de configuração supera uma ferramenta no-code.

Perfis do diretório sempre atualizados

Um script mensal verifica o site de cada agência e registra se ele funciona, mudou de endereço ou está fora do ar. Um rastreamento trimestral lê o site de cada agência e salva os fatos que ela declara, adicionando tags de serviços e setores que o site cita, mas nunca removendo nenhuma. Notas, avaliações e rankings nunca são tocados por nenhum dos dois.

Solicitações aprovadas no Slack

As agências podem pedir para atualizar o perfil ou se candidatar a entrar na lista. Cada solicitação é confirmada por e-mail, conferida pelo Claude com o site da própria agência, salva como rascunho no CMS e enviada ao Slack como um card. Só uma pessoa autorizada pode tocar em Approve, cada clique é verificado com a assinatura de requisição do Slack e cada solicitação só pode ser decidida uma vez.

Tradução de todas as páginas

Todas as páginas do SaaS Hackers também são geradas em alemão, francês, espanhol, holandês, japonês e português do Brasil. O Claude Sonnet 5.5 traduziu o site pela Batch API por US$ 91,35 no total, e as execuções seguintes enviam apenas o texto que mudou. Citações e o que as agências dizem em seus próprios sites permanecem em inglês, palavra por palavra.

Como o SaaS Hackers foi construído nessa stack?

O SaaS Hackers foi reconstruído do Webflow para Astro, Tailwind, Sanity e Netlify com o Claude Code, em fases, cada uma delas um pull request que uma pessoa do SaaS Hackers revisou e aprovou com merge. O arquivo do projeto definia a ordem, as regras e os comandos, e uma especificação escrita definia o que significava “concluído” em cada fase. O lado de design dessa reconstrução está no nosso guia sobre como criar um site com o Claude Code.

A migração levou 233 posts e 172 perfis de especialistas para o Sanity, primeiro como rascunhos, e os comparou com as páginas no ar antes de qualquer publicação. A fase de SEO adicionou uma verificação de que os dados estruturados de todas as páginas são interpretados e uma verificação de paridade com o site no ar. Quando o novo site substituiu o Webflow, a verificação de rotas retornou 494 de 494 endereços no ar, um build de 3.936 páginas (inglês, a versão dos EUA e seis idiomas) levou 8,5 minutos, e o desempenho mobile no Lighthouse ficou entre 99 e 100 nas páginas testadas em produção.

A mesma stack agora sustenta os fluxos de trabalho dos agentes descritos acima. Três coisas tornaram isso possível: um arquivo de projeto que toda sessão lê, scripts que recusam entradas inválidas e uma pessoa que faz o merge do código. Se você quer o lado de operações de marketing desse quadro, nosso guia de operações de marketing para SaaS B2B cobre os dados e as ferramentas ao redor do site.

Quais são os benefícios de um site agêntico?

Os benefícios vêm de o trabalho repetitivo ser feito no prazo, sempre, com um registro do que mudou:

• A manutenção acontece no prazo. Links quebrados, informações desatualizadas e meta descriptions ausentes são corrigidos em uma rotina, e não em uma faxina anual.
• As alterações podem ser desfeitas. Backups, cópias anteriores e pull requests permitem rastrear e reverter qualquer alteração feita por um agente.
• Há menos repasses. Um único agente pode alterar conteúdo, templates e verificações no mesmo pull request, em vez de passar o trabalho entre redator, desenvolvedor e especialista em SEO.
• Os custos de operação podem ser baixos com a stack certa. A própria análise de custos do SaaS Hackers não encontrou cobrança extra de plano de hospedagem para o novo site, e o principal custo a acompanhar são os créditos da Netlify para deploys.

Problemas comuns de sites agênticos e como resolvê-los

O agente comete o mesmo erro duas vezes. Ele não tem memória da sessão anterior. Escreva a regra no CLAUDE.md ou em uma skill no momento em que corrigir o erro, para que toda sessão futura já comece com ela.

As alterações parecem corretas no código, mas ficam erradas na página. Sem uma prévia, ninguém vê a página até ela ir ao ar. Exija um link de prévia de deploy em cada pull request e confira a própria página antes de fazer o merge.

As verificações passam, mas o site continua se desviando do esperado. As verificações só detectam o que testam. Quando algo escapar, adicione ao build uma verificação para esse caso, para que ele não se repita.

Os custos vão subindo. Cada rebuild, rastreamento e chamada de API tem um custo. Defina um limite no briefing de cada agente, agrupe os rebuilds e informe os gastos na passagem de bastão de cada execução.

Ninguém sabe o que o agente alterou. Peça um relatório de entrega após cada tarefa: o que mudou, o backup que ele fez, as verificações que executou e o que não conseguiu fazer.

O que observar ao contratar ajuda para construir um

Se você contratar uma agência ou um desenvolvedor para criar um site agêntico, peça para ver as proteções, não apenas o design. Um bom parceiro vai mostrar:

• um arquivo de instruções do projeto e as regras que ele contém;
• scripts de conteúdo com simulação (dry run) e etapa de backup;
• verificações de build que falham diante de problemas reais, com os comandos para executá-las;
• uma divisão clara entre o que os agentes podem alterar e o que uma pessoa precisa aprovar;
• custos de operação por escrito, incluindo deploys e uso de API.

Você pode comparar especialistas na nossa lista das melhores agências de web design para SaaS B2B.

Sobre o SaaS Hackers

A SaaS Hackers é uma comunidade de especialistas em SaaS B2B que compartilham insights práticos, criada por quem está por trás do crescimento: profissionais de marketing, estrategistas e construtores. Ela publica guias, um manual e listas de melhores, e mantém um diretório de agências e especialistas de marketing para SaaS B2B. A SaaS Hackers é administrada pela Team 4, uma agência de marketing para SaaS B2B que está listada e ranqueada no diretório.