Uma parte cada vez maior dos leitores da sua documentação não é gente. Assistentes de programação buscam a documentação para responder “como integro X”; agentes de suporte leem artigos de ajuda para resolver dúvidas de usuários; agentes de pesquisa resumem registros de alterações para avaliar fornecedores. Serviços de hospedagem de documentação já relatam que uma fatia grande do tráfego vem de agentes de IA, e não de navegadores. Se o seu conteúdo só é legível para uma pessoa rolando uma página renderizada, você fica invisível em um canal que decide cada vez mais se o seu produto é recomendado, integrado ou descartado.
Preparar o conteúdo para agentes se resume a três camadas: um índice fácil de encontrar, um protocolo que máquinas conseguem usar e conteúdo estruturado o bastante para valer a leitura.
Camada 1: llms.txt, o índice que os agentes procuram
llms.txt é uma convenção inspirada no robots.txt: um arquivo Markdown na raiz do seu site (yourapp.com/llms.txt) que diz aos agentes de modelos de linguagem o que é o seu site e onde está o conteúdo importante. O robots.txt diz o que os crawlers não podem fazer; o llms.txt diz o que vale a pena ler: uma descrição curta do produto e, em seguida, uma lista selecionada de links para as páginas principais — seções da documentação, referência da API, registro de alterações, preços.
Um bom llms.txt tem duas qualidades:
Selecionado, não concatenado. O arquivo é um mapa, não um despejo de texto. Aponte para as páginas canônicas da sua documentação; os agentes seguem os links e leem as páginas por conta própria. (Uma convenção irmã, o
llms-full.txt, é a versão com o conteúdo completo, para agentes que querem tudo em uma única requisição. É útil, mas o índice é o que você precisa acertar primeiro.)Gerado, não mantido à mão. Como um sitemap, um llms.txt editado à mão fica desatualizado. Gere o arquivo a partir da mesma API de conteúdo que alimenta as suas páginas, e um artigo publicado entra no índice sozinho. Se o seu conteúdo fica em um backend de conteúdo, isso é uma pequena rota no servidor: buscar as listas e imprimir links em Markdown.
Custo: uma tarde. Retorno: assistentes de IDE e agentes de pesquisa que buscam /llms.txt — e eles já fazem isso hoje — recebem a sua própria descrição do produto em vez de um palpite.
Camada 2: MCP, de legível a operável
O Model Context Protocol (MCP) é o padrão que está se firmando para conectar agentes de IA a sistemas externos como ferramentas. O llms.txt torna o seu conteúdo encontrável; um servidor MCP o torna operável: um agente chama search_entries com a pergunta de um usuário, get_entry para trazer um artigo completo ou lista o seu registro de alterações, tudo como operações estruturadas que devolvem dados estruturados, em vez de raspar HTML.
Na prática, isso muda quem consegue trabalhar com o seu conteúdo:
O agente de programação de um desenvolvedor consulta a sua central de ajuda e o seu registro de alterações de dentro do editor enquanto integra a sua API.
O agente de redação de uma equipe escreve uma entrada do registro de alterações, salva como rascunho e deixa uma pessoa publicar. Se o servidor oferece ferramentas de autoria, o trabalho com o conteúdo passa a ser algo que você delega.
Os seus próprios agentes internos fazem a triagem de posts de feedback ou respondem a perguntas de suporte com base no mesmo conteúdo, sem integração sob medida.
As plataformas de CMS chegaram aqui rápido: várias das grandes lançaram servidores MCP no último ano, e o MCP está virando um item obrigatório na avaliação de plataformas. O Kookee tem um: um servidor MCP sobre o conteúdo de um projeto, que cada membro da equipe conecta com um token pessoal, somente leitura a menos que a pessoa escolha outra coisa, com ferramentas de leitura (listar, buscar, obter) e de autoria (criar, atualizar, publicar, categorizar, fazer a triagem de feedback). Assim, as duas metades do ciclo — agentes que leem o seu conteúdo e agentes que ajudam a produzi-lo — funcionam sem configuração extra. Seja qual for a sua plataforma, a pergunta de avaliação é a mesma: um agente consegue acessar o meu conteúdo como ferramentas, com uma autenticação restrita à pessoa em nome de quem ele age?
Camada 3: conteúdo que vale os tokens
Índices e protocolos entregam o seu conteúdo aos agentes; a estrutura decide o que eles conseguem fazer com ele. Os hábitos que ajudam os agentes são os mesmos que já ajudavam pessoas e mecanismos de busca:
Uma pergunta por artigo, a resposta primeiro. Agentes recuperam trechos. Um artigo que começa pela resposta gera um trecho útil; um que a enterra sob uma introdução gera ruído.
Títulos de seção de verdade e URLs estáveis. A recuperação e a citação dependem de seções com endereço próprio. Quando um agente cita
yourapp.com/help/billing/refunds#timeline, o usuário consegue conferir a resposta.Campos estruturados em vez de convenções no texto. Uma entrada do registro de alterações com uma categoria tipada (“Correção”) e um campo de versão é um dado filtrável; a mesma informação escondida em um parágrafo precisa ser extraída com parsing.
Texto, não capturas de tela de texto. Imagens são opacas para a maioria dos pipelines de recuperação. Use a captura de tela como ilustração, nunca como o único lugar onde um passo aparece.
Datas honestas. Documentação desatualizada engana agentes (e os usuários deles) do mesmo jeito que engana pessoas, só que em escala. Datas nas entradas e um registro de alterações em dia dão aos agentes o sinal de recência para preferir o conteúdo atual.
Um padrão próprio da era dos agentes: artigos de contexto interno. Há coisas que você quer que a sua camada de suporte com IA use sem publicá-las na central de ajuda voltada ao público: limitações conhecidas, detalhes de soluções de contorno, nuances de migração. Um backend de conteúdo com visibilidade só para a IA faz as respostas irem além da documentação pública. Esses artigos ficam fora da central de ajuda pública, mas não são privados: o assistente os cita para qualquer pessoa que perguntar.
O que isso traz, na prática
Preparar o conteúdo para agentes parece abstrato até você seguir um caminho concreto: um desenvolvedor pergunta ao assistente de programação “como pagino resultados no {seu produto}?”. O assistente busca /llms.txt, segue para a documentação da API, lê a seção de paginação e escreve código que funciona, com a fonte citada. Essa interação aconteceu ou com o seu conteúdo, ou com uma resposta de dois anos atrás no Stack Overflow. Multiplique isso por cada decisão de integração, comparação de fornecedores e pergunta de suporte que hoje passa por um agente, e fica claro o que está em jogo.
Uma ordem prática de trabalho
Corrija a estrutura primeiro: artigos com a resposta no início, títulos de seção, campos tipados. Isso melhora a documentação para pessoas hoje, e todo o resto se apoia nisso.
Publique o
/llms.txt, gerado a partir da sua API de conteúdo.Adicione ou adote um servidor MCP — pela sua plataforma de conteúdo, se ela oferecer um.
Procure nos logs os user-agents de agentes e as requisições ao llms.txt; deixe o tráfego real mostrar o que aprofundar.
Nenhum desses passos é grande, e todos se somam: o mesmo conteúdo estruturado, servido por API, que renderiza as suas páginas e alimenta a sua busca é o que torna você legível para o público que mais cresce entre os leitores da sua documentação.