Pular para o conteúdo
Agent Ready

Agentic Web · Web Standards

Como tornar um site Agent-Ready — e o que 100 no IsItAgentReady realmente prova

Agent Readiness não é uma lista de arquivos em /.well-known/. É tratar o agente como um terceiro consumidor de primeira classe — que chega sem sessão, sem layout e sem contexto — e publicar, por leitura de máquina, o que existe, em que formato, sob quais regras e com qual credencial.

16 checks pass
0 checks fail
6 checks neutral
5 Agent-Native

Medido em 7 de setembro de 2026 contra mauricio.issei.com.br pela API do IsItAgentReady. Este placar é estático e datado de propósito: uma página que consulta um avaliador externo em tempo de carregamento troca uma afirmação verificável por uma dependência de terceiro. Reproduza você mesmo — o comando está em Como testar seu site.

01 · O problema

A Web foi construída para humanos e para buscadores

A Web foi construída originalmente para humanos e mecanismos de busca. Agora ela também precisa ser compreensível, descobrível e utilizável por agentes de IA.

O terceiro consumidor chegou sem convite

Um navegador pede HTML e sabe o que fazer com ele: aplica CSS, executa JavaScript, mostra uma página. Um crawler de busca pede o mesmo HTML e extrai dele um índice. Os dois foram previstos pela arquitetura da Web e têm contratos publicados há décadas — Content-Type, robots.txt, sitemap.xml, dados estruturados.

O agente chega sem nada disso. Ele não tem sessão, não renderiza layout, não tem o contexto que um humano acumulou navegando em outras páginas do site, e opera dentro de um orçamento de contexto finito — cada token gasto lendo marcação é um token que não sobra para raciocinar. Quando ele pede a única coisa que o site sabe servir, recebe uma página inteira de aplicação.

O custo disso é mensurável. A página Vibe Coding com Devin deste site responde 197 KB de HTML para um navegador. O mesmo conteúdo, em Markdown, ocupa 3,7 KB. São 52 vezes menos bytes para chegar exatamente ao mesmo texto — e nenhuma linha de layout para desembaraçar.

O que um agente não consegue fazer no seu site hoje

Sem uma superfície publicada para ele, há quatro perguntas que o agente não consegue responder:

  • Quais recursos existem aqui? Ele adivinha caminhos ou desiste.
  • Em que formato eu consigo ler? Ele parseia HTML de aplicação e torce.
  • O que eu posso fazer com este conteúdo? Indexar? Citar? Treinar? Ninguém disse.
  • Como eu invoco uma ação? Não há contrato — só formulários feitos para dedos.

Cada uma dessas perguntas tem hoje um padrão aberto que a responde. Agent Readiness é implementá-las de forma que o agente encontre a resposta sem adivinhar.

02 · Conceito

O que é Agent Readiness

Definição operacional

Agent Readiness é a propriedade de um site cuja superfície pública é projetada para ser consumida por software autônomo: os recursos são descobríveis por mecanismo explícito, o conteúdo é entregue em formato que o agente pede, as regras de uso são declaradas de forma legível por máquina, e as ações disponíveis são publicadas como contratos invocáveis.

O termo ganhou contorno prático com o anúncio de Agent Readiness da Cloudflare, que organizou padrões dispersos — alguns com RFC, outros ainda em rascunho — em um conjunto verificável, e publicou o IsItAgentReady como instrumento de medida.

As cinco propriedades

Cada propriedade responde a uma pergunta que o agente faz antes de agir:

As cinco propriedades de uma superfície agêntica e a pergunta que cada uma responde.
PropriedadePergunta do agenteOnde a resposta mora
Discoverable O que existe aqui? DNS, header Link, robots.txt, sitemap.xml
Readable Em que formato eu leio? Negociação de conteúdo (Accept), Markdown, JSON
Controllable O que posso fazer com isto? Regras para bots de IA, Content Signals
Callable Como eu invoco algo? API Catalog, MCP, A2A, Agent Skills, WebMCP, OAuth
Payable Como eu pago, se houver o que pagar? Protocolos de pagamento agêntico (fora de escopo aqui)

O que Agent Readiness não é

  • Não é bloquear crawler de IA. Bloquear é uma decisão de política que a superfície permite expressar. Um site que bloqueia tudo, e o declara de forma legível, é mais agent-ready do que um que não diz nada.
  • Não é publicar llms.txt e considerar resolvido. Um índice em texto ajuda a leitura; não resolve descoberta, formato, regra de uso nem invocação.
  • Não é criar arquivos em /.well-known/ no chute. Cada documento ali é um contrato. Publicar um contrato que ninguém honra é pior do que não publicar nada — o agente confia no que você declarou.
  • Não é SEO com outro nome. A diferença está na próxima seção.

03 · Evolução

HTML → SEO → AEO → Agent Readiness

Cada onda da Web acrescentou um consumidor e, com ele, um contrato novo. Nenhuma substituiu a anterior: um site em 2026 serve os quatro ao mesmo tempo.

Quatro consumidores da mesma URL, quatro contratos distintos.
CamadaConsumidorO que ele lêO que quebra se faltar
HTMLHumano com navegador Marcação, CSS, JavaScript A página não é usável
SEOCrawler de busca robots.txt, sitemap.xml, <title>, canonical A página não é encontrada
AEOMotor de resposta Dados estruturados, resposta direta, FAQ A página é lida, mas não é citada
Agent ReadinessAgente autônomo Descoberta explícita, formato negociado, regra de uso, contrato invocável A página é citada, mas nada nela pode ser usado

AEO otimiza a citação. Agent Readiness habilita a ação. São objetivos diferentes: um quer que a máquina repita você corretamente; o outro quer que ela faça algo com o que você publicou.

É por isso que a fronteira entre os dois é técnica, não retórica. Um dado estruturado diz o que uma coisa é; um contrato de ferramenta diz o que se pode fazer com ela, com que entrada e sob qual permissão — o mesmo desenho de fronteira discutido em Engenharia de Agentes de IA, onde o MCP aparece como limite de segurança do agente.

04 · Contexto

Antes de continuar: o problema em vídeo

Você acabou de aceitar que existe um quarto consumidor da Web. Falta a intuição de por que isso muda a arquitetura de um site, e não apenas o seu conteúdo. O vídeo abaixo cobre essa pergunta em formato narrativo; o resto desta página cobre a implementação. Se a intuição já está formada, pule direto para a arquitetura em cinco camadas — nada do que vem depois depende de assistir.

O que assistir com atenção

  • A distinção entre ser acessível a um bot e ser projetado para um agente — é o eixo de Do zero ao Agent-Native.
  • Por que o formato de entrega importa tanto quanto o conteúdo — desenvolvido em Content Accessibility.
  • Por que declarar regra de uso é decisão de negócio, não detalhe técnico — desenvolvido em Bot Access Control.

05 · Arquitetura

A arquitetura em cinco camadas

A decisão estrutural deste site foi publicar a superfície agêntica em cinco camadas independentes entre si. Nenhuma depende da outra, e o agente entra por qualquer uma: quem resolve DNS antes de abrir conexão encontra o site; quem faz um GET qualquer recebe o header Link; quem segue convenção vai direto a /.well-known/.

Arquitetura de descoberta em cinco camadas Um agente alcança o site por cinco caminhos independentes: registros DNS sob o nome _agents, o header HTTP Link presente em toda resposta, os documentos em barra well-known, os metadados de autenticação, e as ferramentas registradas em tempo de execução no navegador. Todos convergem para o mesmo conjunto de recursos publicados. USUÁRIO AGENTE 1 · DNS registros HTTPS sob _agents. 2 · HEADER HTTP Link (RFC 8288) em toda resposta 3 · WELL-KNOWN api-catalog · ai-catalog · cards 4 · AUTH auth.md · metadados OAuth 5 · RUNTIME WebMCP no navegador RECURSOS páginas · .md · .json skills · contratos site estático + CDN
Cinco caminhos independentes até o mesmo conjunto de recursos. A redundância é deliberada: nenhum agente precisa conhecer as cinco.

Por que redundância deliberada, e não uma camada só

Porque não existe um agente. Existem muitos, com implementações desiguais: alguns só fazem GET e leem headers; outros conhecem /.well-known/; poucos consultam DNS antes de abrir conexão. Apostar em uma única camada é apostar em um perfil de cliente que você não controla.

A redundância também é a razão de o custo marginal ser baixo. As cinco camadas descrevem os mesmos recursos por caminhos diferentes — publicar um recurso novo custa uma entrada em cada índice, não uma arquitetura nova.

As cinco camadas deste site, com o mecanismo que as descobre.
CamadaOnde viveDescoberta porCusto de operação
DNSRegistros HTTPS/SVCB sob _agents. Resolução DNS, antes de qualquer HTTPZona DNS + DNSSEC
Header HTTPHeader Link na resposta do CDN Qualquer requisição ao sitePolítica de headers no CDN
Well-knownArquivos estáticos em public/.well-known/ Convenção de caminho (RFC 8615)Arquivo versionado no repositório
Authauth.md + metadados OAuth Header Link e /.well-known/Arquivo versionado
Runtimenavigator.modelContext na página Agente que executa dentro do navegadorScript na página

06 · O score, destrinchado

As categorias do score, uma a uma

O IsItAgentReady avalia 22 checks em cinco categorias. O que segue não é a lista dos checks — é o princípio que cada categoria mede, o padrão que o resolve, como implementar, como está implementado aqui e como você verifica sem acreditar em ninguém.

Nota de precisão: a interface do avaliador agrupa a categoria de descoberta como 8/8, enquanto a resposta JSON lista nove entradas em checks.discovery — a nona (ard) aparece em outra agregação da interface. Os nove estão descritos abaixo; o total de 22 e a contagem 16/0/6 não mudam.

6.1 Discoverability — o agente precisa saber o que existe

Discoverability não é ter um sitemap. É dar ao agente mecanismos explícitos para descobrir quais recursos existem e como chegar até eles — em pelo menos duas camadas independentes, porque você não controla qual delas o cliente conhece.

pass robotsTxt RFC 9309
O que mede

Existe um robots.txt válido e ele não impede o acesso ao conteúdo.

Como implementar

Um arquivo em texto na raiz, com pelo menos um grupo User-agent e a diretiva Sitemap apontando para o índice absoluto.

Neste projeto

/robots.txt — versionado em public/robots.txt, servido como está.

Como validar

curl -s https://seu-site/robots.txt

pass sitemap
O que mede

Existe um sitemap.xml alcançável, com URLs absolutas.

O princípio

O sitemap é o inventário do que você quer que seja consumido. A lista de exclusões é tão importante quanto a de inclusões: área administrativa, páginas de teste e utilitários internos não são convite.

Neste projeto

Gerado no build por vite-plugin-sitemap, com lista explícita de exclusões em vite.config.js. Nunca escrito à mão — um sitemap mantido manualmente diverge do site na primeira página nova.

Como validar

curl -sI https://seu-site/sitemap.xml deve responder 200 e application/xml.

pass linkHeaders RFC 8288
O que mede

O site anuncia recursos relacionados no header HTTP, não apenas no corpo do documento.

O princípio

Esta é a camada mais barata para o agente e a mais ignorada por quem implementa. Um HEAD em qualquer URL já entrega o mapa: nenhum download de página, nenhum parser de HTML, nenhuma convenção a adivinhar. É também a única camada que funciona para recursos que não são HTML.

Neste projeto

Sete relações em toda resposta, aplicadas por uma política de headers no CDN — ou seja, fora do repositório. Se o seu site roda em Vercel, Netlify, nginx ou Cloudflare, a receita é a do seu stack; o conteúdo é o mesmo.

Código real deste site resposta HTTP de qualquer URL (quebras de linha adicionadas para leitura)
link: </.well-known/api-catalog>; rel="api-catalog",
      </.well-known/ai-catalog.json>; rel="service-desc"; type="application/json",
      </llms.txt>; rel="service-doc"; type="text/plain",
      </llms-full.txt>; rel="describedby"; type="text/plain",
      </cv-for-ai.md>; rel="service-doc"; type="text/markdown",
      </cv.json>; rel="describedby"; type="application/json",
      </.well-known/oauth-protected-resource>; rel="oauth-protected-resource"
vary: Accept
Como validar
Exemplo genérico shell
curl -sI https://seu-site/ | grep -i '^link\|^vary'
pass dnsAid RFC 9460
O que mede

O domínio publica registros DNS que apontam para os pontos de entrada agênticos — e a resposta é validada por DNSSEC.

O princípio

Descoberta antes do primeiro pacote HTTP. Um agente que resolve _index._agents. do domínio já sabe onde procurar sem ter carregado nada. E aqui há uma regra que a documentação deixa implícita: sem DNSSEC a validação não passa. O registro publicado sem cadeia de confiança é, para o avaliador, um registro que qualquer resolvedor no caminho poderia ter inventado.

Neste projeto

Três nomes (_index, _mcp, _a2a) sob _agents., com a zona assinada. O script de publicação vive em scripts/setup-dns-aid-route53.sh e a operação em docs/DNS_AID_SETUP.md.

Exemplo genérico validação DNS sobre HTTPS — exige Status:0 e AD:true
curl -s -H 'accept: application/dns-json' \
  'https://cloudflare-dns.com/dns-query?name=_index._agents.seu-site&type=HTTPS&do=1'

AD: true é a resposta autenticada. Se vier false, a cadeia DNSSEC não fecha — e nenhum ajuste no registro resolve isso.

6.2 Content Accessibility — o agente precisa ler sem parsear layout

Content accessibility não é ter arquivos .md. É responder no formato que o cliente pediu — na mesma URL, sem exigir que ele conheça um caminho alternativo — e caber no orçamento de contexto dele.

pass markdownNegotiation RFC 7231 §5.3.2
O que mede

Uma requisição com Accept: text/markdown recebe Markdown; um navegador recebe HTML. Mesma URL, formatos diferentes.

O princípio

Negociação de conteúdo é um mecanismo de 1996 que quase ninguém usou, e é exatamente o que o agente precisa. A alternativa comum — publicar /pagina.md como URL separada — funciona, mas obriga o agente a adivinhar a convenção e fragmenta a identidade do recurso: duas URLs para o mesmo conteúdo, dois canônicos, dois lugares para desatualizar.

Como implementar

Uma função na borda do CDN inspeciona o header Accept e reescreve o caminho. Duas armadilhas: comparar os valores de qualidade q (um navegador manda text/html,…,*/*;q=0.8 e não pode receber Markdown), e emitir Vary: Accept — sem ele o CDN entrega a versão em cache errada para o cliente errado.

Neste projeto

infra/cloudfront-functions/viewer-request.js, com os companions .md gerados em public/ pelo mesmo pipeline que gera os metadados.

Código real deste site infra/cloudfront-functions/viewer-request.js
function prefersMarkdown(acceptHeader) {
  if (!acceptHeader) return false;

  var markdownQ = -1;
  var htmlQ     = -1;

  acceptHeader.split(',').forEach(function (part) {
    var tokens = part.trim().split(';');
    var type   = tokens[0].trim().toLowerCase();
    var q      = 1.0;

    for (var i = 1; i < tokens.length; i++) {
      var param = tokens[i].trim();
      if (param.indexOf('q=') === 0) {
        var parsed = parseFloat(param.slice(2));
        q = isNaN(parsed) ? 0 : parsed;
        break;
      }
    }

    if (type === 'text/markdown') {
      markdownQ = q;
    } else if (type === 'text/html') {
      if (q > htmlQ) htmlQ = q;
    }
  });

  return markdownQ > 0 && markdownQ >= htmlQ;
}
Como validar
Exemplo genérico os dois lados da negociação precisam ser testados
# o agente pede Markdown → deve receber text/markdown
curl -s -H 'Accept: text/markdown' -o /dev/null \
  -w '%{content_type}\n' https://seu-site/pagina

# o navegador NÃO pode receber Markdown → deve receber text/html
curl -s -H 'Accept: text/html,application/xhtml+xml,*/*;q=0.8' -o /dev/null \
  -w '%{content_type}\n' https://seu-site/pagina

Este documento responde à mesma negociação: /agent-ready.md é o mesmo conteúdo sem layout.

6.3 Bot Access Control — o agente precisa saber o que pode fazer com o conteúdo

Bot access control não é bloquear. É declarar a regra de uso de forma legível por máquina — indexar sim, treinar não, responder pergunta sim — para que o agente que respeita regras saiba qual é a sua, sem precisar inferir a partir de termos de uso escritos para advogados.

pass robotsTxtAiRules
O que mede

Se o robots.txt trata bots de IA — por regra específica ou por um curinga que os alcança.

A leitura honesta

Aqui o check passa com a mensagem "No AI-specific bot rules; wildcard rules apply to all crawlers including AI bots". Ou seja: ele passa por ausência de bloqueio, não por presença de regra. Entender essa diferença vale mais do que comemorar o verde — se a sua política for diferente por agente, é você que precisa escrevê-la; o curinga não decide nada por você.

Neste projeto

User-agent: * com Allow: /, e as exclusões restritas a diretórios internos.

pass contentSignals Content Signals
O que mede

Presença da diretiva Content-Signal no robots.txt, declarando os usos permitidos do conteúdo.

O princípio

robots.txt responde se o bot pode buscar. Content Signals responde o que ele pode fazer depois de ter buscado — três decisões independentes: aparecer em busca, ser usado como fonte de resposta, ser usado para treinar modelo. São perguntas distintas e merecem respostas distintas.

Neste projeto

Indexar sim, servir de insumo para resposta sim, treinar não.

Código real deste site public/robots.txt (trecho)
User-agent: *
Allow: /
Content-Signal: ai-train=no, search=yes, ai-input=yes

Sitemap: https://mauricio.issei.com.br/sitemap.xml
Agentmap: https://mauricio.issei.com.br/.well-known/ai-catalog.json
LLMs: https://mauricio.issei.com.br/llms.txt
LLMs-full: https://mauricio.issei.com.br/llms-full.txt
neutral webBotAuth Web Bot Auth
O que mede

Se o site publica um diretório de chaves que permite verificar criptograficamente a identidade de um bot, por assinatura de mensagem HTTP.

O princípio

O User-Agent é uma string que qualquer cliente escreve. Web Bot Auth substitui declaração por prova: o bot assina a requisição, e o site valida contra a chave publicada. É a diferença entre dizer que é um agente conhecido e demonstrar que é.

Estado aqui

Neutro — não implementado. Faz sentido para quem precisa distinguir bot legítimo de imitador e aplicar política diferente a cada um. Para um site de conteúdo público, cujo Content Signal já é o mesmo para todos, não muda nenhuma decisão. Um check neutro não penaliza a nota — e é justamente por isso que ele não atesta nada. Ver os limites do score.

6.4 API, Auth, MCP & Skill Discovery — o agente precisa poder agir

Protocol discovery não é publicar JSON em /.well-known/. É publicar um contrato que alguém pode invocar — com entrada tipada, permissão declarada e documentação alcançável a partir do próprio contrato.

Esta é a categoria mais densa: nove documentos, cada um respondendo a uma pergunta diferente sobre ação. A tabela resume; os cartões detalham os que exigem decisão.

Os nove documentos de descoberta de protocolo e o que cada um resolve.
CheckPadrãoPergunta que respondeNeste projeto
apiCatalog RFC 9727 Que APIs existem e onde está a especificação de cada uma? /.well-known/api-catalog
ardAgent Resource Descriptor Que recursos legíveis por agente existem, com identificador estável? /.well-known/ai-catalog.json
oauthDiscovery RFC 8414 Quem emite credencial para este recurso? /.well-known/openid-configuration
oauthProtectedResource RFC 9728 Que escopos este recurso exige e onde está a política? /.well-known/oauth-protected-resource
authMdauth.md Como um agente se autentica aqui, em prosa que ele consegue seguir? /auth.md
mcpServerCard MCP Que ferramentas e recursos este domínio expõe por MCP? /.well-known/mcp/server-card.json
a2aAgentCard A2A Que habilidades este domínio oferece a outros agentes? /.well-known/agent-card.json
agentSkills Agent Skills Que procedimentos reutilizáveis eu posso carregar daqui? /.well-known/agent-skills/index.json
webMcp WebMCP Que ações eu posso executar sem sair da página? src/index.html
pass apiCatalog RFC 9727
O princípio

Um linkset: para cada recurso (anchor), quais links tipados existem. Uma especificação legível por máquina (service-desc), a documentação em prosa (service-doc), o estado (status). O agente descobre a API e como entendê-la em uma única requisição.

Exemplo genérico /.well-known/api-catalog — uma âncora, o mínimo válido
{
  "linkset": [
    {
      "anchor": "https://seu-site/dados.json",
      "service-desc": [
        { "href": "https://seu-site/openapi.json",
          "type": "application/openapi+json;version=3.0" }
      ],
      "service-doc": [
        { "href": "https://seu-site/dados.md", "type": "text/markdown" }
      ]
    }
  ]
}
pass oauthProtectedResource · authMd RFC 9728
O princípio

Autenticação para agentes tem duas faces. A máquina precisa dos metadados: qual servidor de autorização, quais escopos, onde está a política de privacidade. O agente precisa de instruções em prosa — auth.md é literalmente isso: um documento Markdown que descreve o fluxo, para ser lido por quem raciocina em linguagem natural.

Vale para acesso anônimo também. "Nenhuma credencial é necessária, e estes são os escopos disponíveis" é uma declaração útil — evita que o agente tente um fluxo que não existe.

Código real deste site public/.well-known/oauth-protected-resource
{
  "resource": "https://mauricio.issei.com.br",
  "authorization_servers": ["https://mauricio.issei.com.br"],
  "scopes_supported": ["cv:read", "projects:read", "profile"],
  "bearer_methods_supported": ["header"],
  "resource_documentation": "https://mauricio.issei.com.br/cv-for-ai.md",
  "resource_policy_uri": "https://mauricio.issei.com.br/privacidade"
}

O documento de autorização deste site declara identidade anônima explicitamente. O formato exato — e por que ele custou três iterações de deploy — está em o caso do agent_auth.

pass agentSkills Agent Skills
O princípio

Uma skill é procedimento, não dado: "como fazer X neste domínio", escrito para ser carregado no contexto de um agente. O índice aponta para cada SKILL.md e traz o digest SHA-256 do arquivo — o agente verifica que carregou o que o índice prometeu, e não algo trocado no caminho. Instrução que entra no contexto de um modelo é superfície de ataque; o digest é o que a torna verificável.

Neste projeto

Duas skills — convenções deste repositório e acesso aos dados estruturados do currículo —, cada uma com digest.

Código real deste site public/.well-known/agent-skills/index.json (trecho)
{
  "$schema": "https://schemas.agentskills.io/discovery/0.2.0/schema.json",
  "skills": [
    {
      "name": "cv-data-access",
      "type": "skill-md",
      "description": "How to retrieve and parse structured CV data…",
      "url": "https://mauricio.issei.com.br/.well-known/agent-skills/cv-data-access/SKILL.md",
      "digest": "sha256:95a3d61a86da45cae9037e0f4f7d41a64a37cc4f2a61567791b95c2f5a2178ec"
    }
  ]
}
pass webMcp WebMCP
O princípio

As outras oito camadas são estáticas: documentos publicados que o agente lê de fora. WebMCP é a única em tempo de execução — a página registra ferramentas no navegador, e um agente que esteja rodando ali dentro pode invocá-las com a sessão do usuário, sem servidor intermediário.

É proposta em evolução, então o registro vai atrás de um teste de existência. Sem navigator.modelContext, nada acontece e a página segue idêntica.

Código real deste site src/index.html (trecho)
if (typeof navigator.modelContext !== 'undefined') {
    const controller = new AbortController();
    const signal = controller.signal;

    navigator.modelContext.registerTool({
        name: 'get_cv_data',
        description: 'Retrieve the full structured curriculum vitae in JSON format.',
        inputSchema: { type: 'object', properties: {} },
        execute: async () => {
            const response = await fetch('/cv.json');
            return await response.json();
        }
    }, { signal });
}

6.5 Commerce — por que cinco checks ficam neutros aqui

Os cinco checks de comércio agêntico — pagamento máquina-a-máquina, catálogo de produtos para agentes, protocolos de checkout — vêm marcados como neutral: "not a commerce site". Este site não vende nada, então não há transação a descrever.

A decisão de escopo importa mais que o resultado. Publicar um protocolo de pagamento sem ter o que cobrar é ruído no contrato: o agente lê uma capacidade que não existe. A regra geral vale para todas as categorias — declare o que você tem, e só isso.

07 · Progressão

Do zero ao Agent-Native

O avaliador resume o resultado em um nível de 1 a 5. Ele não é uma soma de arquivos: cada degrau acrescenta uma das cinco propriedades da §2, e a ordem importa — não adianta publicar contrato invocável para um agente que ainda não consegue descobrir que o recurso existe.

Acessível

O bot consegue buscar: responde 200, não há bloqueio geral, existe robots.txt. É o piso — e é onde a maioria dos sites está sem ter feito nada.

Descobrível

Existe um inventário explícito do que o site oferece: sitemap, e alguma forma de anunciar recursos além das páginas HTML.

Legível

O conteúdo é entregue em formato que o agente consegue consumir com baixo custo de contexto — negociação de conteúdo, ou pelo menos versões estruturadas dos recursos principais.

Governado

As regras de uso são declaradas por máquina: o que pode ser indexado, citado, usado como insumo de resposta, usado para treinar.

Agent-Native

Existem contratos invocáveis publicados e descobríveis — APIs catalogadas, ferramentas declaradas, autenticação documentada. O agente não só lê: ele sabe o que pode fazer e como pedir permissão.

"Site que um bot consegue acessar" ≠ "site projetado para agentes". O primeiro não bloqueia, responde 200 e tem sitemap — o agente ainda precisa adivinhar tudo. No segundo, o agente descobre sem adivinhar, lê no formato que pediu, sabe a regra de uso e encontra um contrato invocável. A diferença não é de quantidade de arquivos: é de quem carrega o ônus da inferência.

08 · Estudo de caso

Este site, na prática

O que segue são as implementações reais deste domínio, no formato problema → solução → implementação → validação → impacto. O impacto é sempre qualitativo ou uma contagem medida: este site não instrumenta tráfego de agentes, então não há percentual a apresentar — e inventar um seria exatamente o tipo de afirmação que a página existe para desencorajar.

Os três casos mais úteis são os que deram errado primeiro.

Problema

O site publicava dados estruturados, currículo em Markdown e catálogos — e nada disso era anunciado. Um agente que fizesse GET / recebia uma página HTML e nenhuma pista de que havia mais.

Solução

Header Link (RFC 8288) com sete relações tipadas em toda resposta do site, não apenas na home.

Implementação

Uma política de headers aplicada na borda do CDN, com Vary: Accept junto. Fica fora do repositório por natureza — é configuração de infraestrutura, não arquivo servido.

Validação

curl -sI https://mauricio.issei.com.br/ | grep -i '^link'

Impacto

O agente descobre a superfície inteira em uma requisição HEAD, sem baixar página nem conhecer convenção de caminho.

O agente lia 197 KB de HTML para extrair 3,7 KB de texto

Problema

Todo conteúdo só existia como página de aplicação. Um agente pagava o custo integral de marcação, estilo e script para chegar ao texto.

Solução

Negociação de conteúdo na mesma URL: Accept: text/markdown devolve o companion .md; qualquer outro cliente recebe HTML.

Implementação

Função na borda (infra/cloudfront-functions/viewer-request.js) comparando os valores q, mais companions .md gerados pelo mesmo pipeline que produz os metadados — nunca escritos à mão, para não divergirem da página.

Validação

Os dois lados: Accept: text/markdown → text/markdown; Accept de navegador → text/html.

Impacto

52 vezes menos bytes para o mesmo conteúdo, sem uma segunda URL a manter e sem alterar nada para navegadores.

⚠ Incidente

A negociação de Markdown derrubou 21 URLs do índice de busca

Problema

A negociação de Markdown foi escrita como uma função nova na borda, ao lado da função que já existia para resolver URLs sem extensão. Um comportamento de cache aceita uma função associada por tipo de evento. Ao associar a de Markdown, a outra saiu — e toda URL sem .html passou a responder 404. Vinte e uma páginas apareceram como "Não encontrado" no Search Console: exatamente as do sitemap.

Solução

Uma função única, com as responsabilidades em ordem explícita: normalizar barra final → negociar Markdown → resolver raiz → sufixar .html.

Implementação

Duas guardas nasceram do incidente. A primeira: /.well-known/ é isento da sufixação — é um registro de nomes sem extensão, e sufixar .html ali quebraria a descoberta inteira. A segunda: o teste de extensão olha o último segmento da URI, não a URI inteira — o teste antigo desligava a regra por causa de qualquer ponto em qualquer lugar do caminho.

Validação

Um teste unitário que avalia a função em um contexto isolado, com um caso para cada URL que o Search Console viu falhar (tests/cloudfront-viewer-request.test.js). O teste roda no gate, antes de qualquer deploy.

Impacto

As 21 URLs voltaram a responder 200 e a regressão virou um caso de teste — que é o único desfecho que impede o incidente de acontecer de novo.

Código real deste site infra/cloudfront-functions/viewer-request.js — as duas guardas do incidente
// `/.well-known/*` é um registro IANA de nomes SEM extensão
// (api-catalog, openid-configuration, oauth-protected-resource…).
// Sufixar `.html` ali quebraria a descoberta por agentes.
if (uri.indexOf('/.well-known/') === 0) {
  return request;
}

// O teste antigo era `!uri.includes('.')`, que olhava a URI inteira:
// qualquer ponto em qualquer lugar do caminho desligava a regra.
var lastSegment = uri.slice(uri.lastIndexOf('/') + 1);
if (lastSegment.indexOf('.') === -1) {
  request.uri = uri + '.html';
}

O agente não sabia se podia treinar com o conteúdo

Problema

A política de uso existia apenas nos termos do site — texto jurídico, escrito para humanos, que nenhum crawler interpreta.

Solução

Uma linha Content-Signal no robots.txt, separando as três decisões: indexar, servir de insumo para resposta, treinar.

Implementação

ai-train=no, search=yes, ai-input=yes — o conteúdo pode ser encontrado e citado; não pode virar peso de modelo.

Validação

curl -s https://mauricio.issei.com.br/robots.txt | grep Content-Signal

Impacto

A política deixou de depender de interpretação. Um agente que respeita regras agora tem uma regra para respeitar.

⚠ Incidente

O check de autenticação falhou três vezes seguidas

Problema

O acesso a este site é anônimo, e a declaração disso parecia trivial. Não era: três deploys seguidos falharam o check, com uma mensagem de remediação genérica que não mudava entre as tentativas.

Solução

Três regras não óbvias, descobertas uma a uma:

  • o bloco de autenticação de agente vive nos metadados do servidor de autorização, não no auth.md;
  • o campo que aponta para a documentação em prosa deve referenciar o auth.md publicado;
  • a tríade que declara identidade anônima precisa estar dentro do bloco — repetida na lista de métodos ou no topo do documento, é ignorada.
Implementação

public/.well-known/oauth-authorization-server, com o bloco no formato aceito, e public/auth.md descrevendo o fluxo em prosa.

Validação

Um teste dedicado (tests/oauth-discovery.spec.js) verifica a forma dos metadados e a presença deles nos catálogos — a estrutura que custou três deploys não regride em silêncio.

Impacto

Além do check: a lição de método. A mensagem no topo do relatório é fixa por check; o sinal real está no detalhe da evidência, dentro do JSON. Cada correção revelava a próxima mensagem de uma fila de validadores, enquanto o texto de topo permanecia idêntico. Ver Ler o JSON.

⚠ Incidente

Os registros DNS publicados e o check ainda em falha

Problema

Os três registros de descoberta estavam no ar e resolviam corretamente. O check continuava vermelho.

Solução

O avaliador exige que a resposta seja validada por DNSSEC. Registro correto em zona não assinada não passa — e nenhuma mudança no registro resolveria.

Implementação

Assinatura da zona com chave gerenciada, e publicação manual do registro DS no registrador do domínio — no caso de um .com.br, um formulário no Registro.br e cerca de quatro horas de propagação.

Validação

Consulta DNS sobre HTTPS com do=1: a resposta precisa trazer "Status": 0 e "AD": true. O AD é o sinal de que a cadeia fechou.

Impacto

O check passou — e o domínio inteiro passou a depender da chave de assinatura. Isso muda o procedimento de reversão: para desligar DNSSEC é preciso remover o DS no registrador primeiro e aguardar a propagação completa antes de desativar a assinatura. Na ordem inversa, o domínio inteiro fica irresolvível para resolvedores validantes. Não é um detalhe de operação: é a diferença entre uma reversão e um apagão.

Dar ao agente ações, e não apenas texto

Problema

Toda a superfície era leitura. Um agente rodando dentro do navegador do usuário não tinha nada para fazer além de raspar a página.

Solução

Duas ferramentas registradas via navigator.modelContext: currículo estruturado e casos de projeto.

Implementação

Registro condicionado à existência da API, com AbortController para o ciclo de vida. Sem suporte no navegador, nada acontece.

Validação

O avaliador reporta as ferramentas encontradas pelo nome — se o registro quebrar, o check acusa.

Impacto

A superfície passou a ter uma camada de execução, além das quatro de leitura.

09 · Implementação

Tutorial: implemente no seu site

Oito etapas em ordem crescente de custo. As quatro primeiras são arquivos estáticos e resolvem a maior parte do resultado; as quatro últimas exigem decisão de arquitetura. Faça na ordem: cada etapa pressupõe a anterior.

Os blocos de código marcados como exemplo genérico são para você copiar e adaptar. Os marcados como código real deste site são o que está de fato publicado aqui, com o caminho do arquivo.

Etapa 1 Discoverability

Objetivo: o agente descobre quais recursos existem sem adivinhar caminhos.

Pré-requisito: nenhum.

Implementação: (a) robots.txt na raiz com Sitemap: absoluto; (b) sitemap.xml gerado pelo build, nunca à mão; (c) header Link anunciando os recursos que não são páginas.

Aviso: o header Link exige controle do servidor ou do CDN. Não é um arquivo que você comita — é configuração de plataforma (headers no Vercel/Netlify, add_header no nginx, regra de transformação no Cloudflare, política de headers na CloudFront). Se você não tem esse controle, faça as outras camadas e volte aqui depois.

Exemplo genérico o mínimo que já muda o resultado
Link: </.well-known/api-catalog>; rel="api-catalog",
      </llms.txt>; rel="service-doc"; type="text/plain"
Vary: Accept

Validação: curl -sI https://seu-site/ | grep -i '^link'

Etapa 2 Content accessibility

Objetivo: entregar o conteúdo em formato barato de consumir.

Pré-requisito: Etapa 1 — o agente precisa saber que o recurso existe.

Implementação: gere um companion .md por página, a partir da mesma fonte que gera a página. Depois faça a borda inspecionar Accept e servir o .md quando pedido. Emita Vary: Accept — sem ele, o CDN entrega a versão em cache errada e o navegador de alguém baixa Markdown.

Atalho aceitável: se a borda não é sua, publique /pagina.md como URL e anuncie no header Link … rel="alternate"; type="text/markdown". Menos elegante, resolve.

Validação: os dois lados da negociação, sempre — o caminho do navegador é o que quebra em silêncio.

Etapa 3 Bot access control

Objetivo: declarar por máquina o que pode ser feito com o conteúdo.

Pré-requisito: uma decisão de negócio, não uma decisão técnica. Decida antes de escrever.

Implementação: acrescente Content-Signal ao robots.txt. Três eixos independentes:

Exemplo genérico robots.txt
User-agent: *
Allow: /
Content-Signal: ai-train=no, search=yes, ai-input=yes

search = aparecer em busca · ai-input = ser usado como fonte de uma resposta gerada · ai-train = virar dado de treinamento.

Validação: curl -s https://seu-site/robots.txt | grep Content-Signal

Etapa 4 API e protocol discovery

Objetivo: publicar o inventário de contratos.

Pré-requisito: ter pelo menos um recurso estruturado — um JSON, uma API, um documento de dados.

Implementação: um /.well-known/api-catalog (RFC 9727) com uma âncora por recurso. Se você não tem OpenAPI, aponte service-doc para a documentação em Markdown; um catálogo com documentação em prosa é melhor que catálogo nenhum.

Validação: curl -s https://seu-site/.well-known/api-catalog | jq .

Confira também o Content-Type da resposta: objetos sem extensão de arquivo tendem a sair com o tipo padrão do storage em vez de application/linkset+json. O avaliador tolera; outras ferramentas não têm por que tolerar.

Etapa 5 MCP

Objetivo: declarar as ferramentas e recursos que o domínio expõe pelo Model Context Protocol.

Pré-requisito: saber quais ações você quer oferecer — e estar disposto a mantê-las.

Implementação: um server card em /.well-known/mcp/server-card.json, descrevendo nome, ferramentas e recursos. Cada ferramenta é uma função com entrada tipada; cada recurso é um documento que o agente pode carregar.

Aviso, e é o mais importante do tutorial: um card é a descrição de um contrato. Declare exatamente aquilo que você está pronto para sustentar — a descoberta e a execução são coisas distintas, e o agente confia no que você declarou. Ver O que um score 100 não prova.

Validação: curl -s https://seu-site/.well-known/mcp/server-card.json | jq . — e, para cada capacidade declarada, um teste que exercite a capacidade de verdade.

Etapa 6 Agent Skills

Objetivo: publicar procedimento reutilizável, não apenas dado.

Pré-requisito: ter algo que se repete e que hoje mora na cabeça de alguém.

Implementação: um SKILL.md por procedimento e um index.json que os lista. Publique o digest SHA-256 de cada arquivo: instrução que entra no contexto de um modelo precisa ser verificável.

Exemplo genérico gerar o digest de uma skill
printf 'sha256:%s\n' "$(sha256sum SKILL.md | cut -d' ' -f1)"

Validação: baixe o SKILL.md pela URL publicada e confira o digest — se não bater, o índice está velho.

Etapa 7 Autenticação e OAuth

Objetivo: dizer ao agente como obter permissão — mesmo que a resposta seja "não precisa".

Pré-requisito: saber quais escopos fazem sentido no seu domínio.

Implementação: (a) /.well-known/oauth-protected-resource (RFC 9728) com resource, authorization_servers, scopes_supported e a política; (b) um auth.md descrevendo o fluxo em prosa, para o agente ler; (c) os metadados do servidor de autorização (RFC 8414), declarando os tipos de identidade aceitos.

Se o acesso é anônimo, diga isso explicitamente. Declarar identidade anônima é mais útil do que omitir — evita que o agente tente um fluxo inexistente. E declare apenas os endpoints que respondem: metadado de autorização é contrato, não formulário a preencher.

Validação: um teste automatizado sobre a forma do documento. Esta é a parte da superfície mais fácil de quebrar por edição manual.

Etapa 8 Avançado: DNS, runtime e identidade de bot

Objetivo: as camadas que exigem infraestrutura ou APIs em evolução.

DNS-AID: registros HTTPS/SVCB sob _agents. do seu domínio. Exige DNSSEC — e assinar a zona torna a chave de assinatura um ponto único de falha do domínio inteiro. Antes de habilitar, escreva o procedimento de reversão: remover o DS no registrador, aguardar a propagação completa e só então desativar a assinatura. Nessa ordem.

WebMCP: registre ferramentas em navigator.modelContext, sempre atrás de um teste de existência. É proposta em evolução; o código precisa degradar em silêncio.

Web Bot Auth: publique um diretório de chaves para que agentes possam provar identidade por assinatura. Vale quando você precisa tratar bots de forma diferente uns dos outros — se a sua política é a mesma para todos, não muda nada.

10 · Validação

Como testar seu site

Rodar o scan

Pela interface do IsItAgentReady, ou direto pela API — que é o que você quer quando estiver iterando:

Exemplo genérico shell
curl -s -X POST https://isitagentready.com/api/scan \
  -H 'content-type: application/json' \
  -d '{"url":"https://seu-site"}' > scan.json

Ler o JSON: onde está o sinal de verdade

Esta é a parte que economiza horas. O texto de remediação exibido na interface é fixo por check: ele é idêntico em todo site que falha aquele check e não muda entre as suas tentativas. Corrigir com base nele é tentar acertar no escuro.

O sinal real está no detalhe das evidências, dentro do JSON. Cada check reprovado costuma passar por uma fila de validadores, e a evidência aponta qual deles reprovou — de modo que cada correção revela a mensagem seguinte, enquanto o texto de topo permanece igual. Ler o JSON é o que transforma "não passou" em "faltou este campo aqui".

Exemplo genérico extrair só o que falhou, com a evidência
jq '[.checks | to_entries[] | .value | to_entries[]
     | select(.value.status != "pass")
     | { check: .key, status: .value.status,
         evidence: (.value.evidence // []) }]' scan.json

O ciclo corrigir → publicar → rescanear

  1. Corrija um check por vez. Duas correções no mesmo deploy e você não sabe qual funcionou.
  2. Publique. Um scan roda contra produção, não contra o seu repositório.
  3. Rescaneie e leia a evidência, não o texto de remediação.
  4. Quando passar, escreva o teste. Um check que passou sem teste é um check que vai regredir.

Confira o que está no ar, não o que está no repositório. O erro mais comum de diagnóstico nesta jornada é olhar o arquivo local, vê-lo correto, e concluir que o avaliador está errado — quando o deploy simplesmente ainda não saiu, ou o cache da borda ainda serve a versão anterior.

Neste repositório essa disciplina é automatizada: as verificações de estrutura, os testes unitários da função de borda, a auditoria de coerência do site e a suíte de navegador com axe rodam em um gate único antes de qualquer push. O resultado do avaliador externo é a confirmação final, não o mecanismo de controle.

11 · Limites

O que um score 100 não prova

Esta é a seção que justifica a página existir. Um número redondo convida a parar de pensar; o valor dele está inteiramente em saber o que ele mede.

Metadado de descoberta não é runtime

Os checks de descoberta validam documentos: o arquivo existe, é JSON válido, tem os campos obrigatórios, está no caminho previsto. Eles não abrem conexão com o que o documento descreve, não invocam ferramenta, não completam fluxo de autorização.

A consequência prática é uma regra de engenharia, não uma crítica ao instrumento: o contrato que você publica é uma promessa, e quem a cumpre é o serviço, não o arquivo. Declare o que você sustenta; teste cada capacidade declarada exercitando-a de verdade, não relendo o documento que a anuncia. Nenhum avaliador de metadados vai fazer isso por você.

Neutral não é pass

Dos 22 checks, seis vêm neutros neste site: cinco de comércio agêntico (por decisão de escopo — não há transação a descrever) e um de identidade criptográfica de bot (não implementado). Um check neutro não penaliza a nota, e é exatamente por isso que ele não atesta nada. Um instrumento que não pune a ausência não certifica a presença.

Ler "100" como "22 de 22" é o erro. São 16 verificados, seis não avaliados — e o segundo número é informação, não ruído: ele diz onde a superfície ainda não foi exercida.

A régua é o instrumento, não a realidade

Um score 100 significa uma coisa precisa: o site passou nos checks que aquele instrumento considerou, naquela configuração, naquela data. Não significa que qualquer agente consegue fazer qualquer coisa no site. Não significa que os padrões escolhidos são os que vão vencer — boa parte deles ainda é rascunho, e alguns serão substituídos. E não significa que a superfície continua correta amanhã: ela é código, e código regride.

O valor do exercício não é o número. É que ele obriga a responder, de forma verificável, as quatro perguntas do início desta página — o que existe, em que formato, sob quais regras, com qual credencial. Um site que responde bem a essas quatro perguntas continua agent-ready mesmo quando a régua mudar.

Em síntese

O que é Agent Readiness

Agent Readiness não é uma lista de arquivos em `/.well-known/`. É tratar o agente como um terceiro consumidor de primeira classe — que chega sem sessão, sem layout e sem contexto — e publicar, por leitura de máquina, o que existe, em que formato, sob quais regras e com qual credencial.

  • Discoverable — descoberta explícita em camadas independentes: DNS, header `Link` (RFC 8288), `robots.txt`, sitemap.
  • Readable — negociação de conteúdo: `Accept: text/markdown` na mesma URL, com `Vary: Accept`.
  • Controllable — regra de uso legível por máquina: `Content-Signal: ai-train=no, search=yes, ai-input=yes`.
  • Callable — contratos invocáveis: API Catalog (RFC 9727), MCP Server Card, Agent Skills com digest, WebMCP.

Estudo de caso auditável: este domínio mede 16 pass · 0 fail · 6 neutral · nível 5 (Agent-Native) no IsItAgentReady, medido em 7 de setembro de 2026.

Perguntas frequentes

Perguntas frequentes

O que é Agent Readiness?

Agent Readiness é a propriedade de um site cuja superfície pública foi projetada para ser consumida por software autônomo: os recursos são descobríveis por mecanismo explícito, o conteúdo é entregue no formato que o agente pede, as regras de uso são declaradas de forma legível por máquina e as ações disponíveis são publicadas como contratos invocáveis. É uma camada nova sobre HTML, SEO e AEO — não uma substituição de nenhuma delas.

O que significa ser Agent-Ready?

Significa que um agente consegue responder quatro perguntas sobre o seu site sem adivinhar: quais recursos existem, em que formato consegue lê-los, o que pode fazer com o conteúdo e como invoca uma ação. Um site apenas acessível a bots responde 200 e não bloqueia; um site agent-ready transfere para si o ônus da inferência, publicando cada uma dessas respostas de forma verificável.

Como alcançar score 100 no IsItAgentReady?

Implementando as categorias em ordem: descoberta (robots.txt, sitemap, header Link RFC 8288, registros DNS com DNSSEC), acessibilidade de conteúdo (negociação Accept: text/markdown com Vary: Accept), controle de acesso (Content Signals), e descoberta de protocolo (API Catalog RFC 9727, metadados OAuth RFC 8414/9728, auth.md, MCP server card, A2A agent card, Agent Skills e WebMCP). Corrija um check por vez, publique, e leia a evidência no JSON do scan em vez do texto genérico da interface.

O que é Markdown para agentes?

É entregar a mesma URL em Markdown quando o cliente envia Accept: text/markdown, por negociação de conteúdo (RFC 7231 §5.3.2). Uma página de aplicação com 197 KB de HTML costuma caber em poucos KB de Markdown — neste site, 3,7 KB para o mesmo texto, 52 vezes menos bytes. Duas armadilhas: comparar os valores de qualidade q, já que um navegador manda /;q=0.8 e não pode receber Markdown, e emitir Vary: Accept para o CDN não servir a versão errada.

O que é um MCP Server Card?

É um documento JSON em /.well-known/mcp/server-card.json que descreve, de forma legível por máquina, quais ferramentas e recursos um domínio expõe pelo Model Context Protocol: nome do servidor, transporte, ferramentas com entrada tipada e recursos carregáveis. Ele é a camada de descoberta — a descrição do contrato. Publique nele exatamente as capacidades que você está pronto para sustentar.

O que são Agent Skills?

Agent Skills publicam procedimento reutilizável, não dado: cada skill é um arquivo SKILL.md com instruções sobre como fazer algo naquele domínio, listado em um index.json com a URL e o digest SHA-256 do arquivo. O digest é o ponto central — instrução que entra no contexto de um modelo é superfície de ataque, e o digest permite ao agente verificar que carregou o que o índice prometeu.

Como agentes descobrem APIs?

Pelo API Catalog da RFC 9727: um linkset em /.well-known/api-catalog que, para cada recurso (anchor), lista links tipados — service-desc para a especificação legível por máquina, service-doc para a documentação em prosa, status para o estado. O mesmo catálogo pode ser anunciado no header Link (RFC 8288), o que permite ao agente descobrir tudo com uma requisição HEAD, sem baixar página nem conhecer convenção de caminho.

Como controlar o acesso de AI bots?

Com duas camadas complementares. O robots.txt (RFC 9309) responde se o bot pode buscar. A diretiva Content-Signal responde o que ele pode fazer depois de ter buscado, separando três decisões independentes: search (aparecer em busca), ai-input (ser usado como fonte de uma resposta gerada) e ai-train (virar dado de treinamento). Para distinguir bots uns dos outros por identidade criptográfica, existe ainda o Web Bot Auth, baseado em assinatura de mensagem HTTP.

Como testar se um site é Agent-Native?

Rode um scan no IsItAgentReady — pela interface ou por POST na API — e leia o JSON, não o texto de remediação da interface, que é fixo por check e idêntico em todo site que falha aquele check. O sinal real está no detalhe das evidências, que aponta qual validador reprovou. Depois corrija um check por vez, publique (o scan roda contra produção, não contra o repositório), rescaneie e escreva um teste para cada check que passou.

Um score 100 significa que o site é perfeito para agentes?

Não. Significa algo preciso e limitado: o site passou nos checks que aquele instrumento considerou, naquela configuração, naquela data. Os checks de descoberta validam documentos — que o arquivo existe, é JSON válido e tem os campos obrigatórios —, não abrem conexão com o que o documento descreve. Além disso, checks neutros não penalizam a nota e por isso também não atestam nada: um instrumento que não pune a ausência não certifica a presença.