- O que mede
Existe um
robots.txtvá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-agente a diretivaSitemapapontando 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
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.
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:
| Propriedade | Pergunta do agente | Onde 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.txte 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.
| Camada | Consumidor | O que ele lê | O que quebra se faltar |
|---|---|---|---|
| HTML | Humano com navegador | Marcação, CSS, JavaScript | A página não é usável |
| SEO | Crawler de busca | robots.txt, sitemap.xml, <title>, canonical |
A página não é encontrada |
| AEO | Motor de resposta | Dados estruturados, resposta direta, FAQ | A página é lida, mas não é citada |
| Agent Readiness | Agente 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/.
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.
| Camada | Onde vive | Descoberta por | Custo de operação |
|---|---|---|---|
| DNS | Registros HTTPS/SVCB sob _agents. |
Resolução DNS, antes de qualquer HTTP | Zona DNS + DNSSEC |
| Header HTTP | Header Link na resposta do CDN |
Qualquer requisição ao site | Política de headers no CDN |
| Well-known | Arquivos estáticos em public/.well-known/ |
Convenção de caminho (RFC 8615) | Arquivo versionado no repositório |
| Auth | auth.md + metadados OAuth |
Header Link e /.well-known/ | Arquivo versionado |
| Runtime | navigator.modelContext na página |
Agente que executa dentro do navegador | Script 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.
- O que mede
Existe um
sitemap.xmlalcançá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 emvite.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.xmldeve responder200eapplication/xml.
- 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
HEADem 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.
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'
- 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 emscripts/setup-dns-aid-route53.she a operação emdocs/DNS_AID_SETUP.md.
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.
- O que mede
Uma requisição com
Accept: text/markdownrecebe 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.mdcomo 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
Accepte reescreve o caminho. Duas armadilhas: comparar os valores de qualidadeq(um navegador mandatext/html,…,*/*;q=0.8e não pode receber Markdown), e emitirVary: 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.mdgerados empublic/pelo mesmo pipeline que gera os metadados.
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.
- O que mede
Se o
robots.txttrata 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: *comAllow: /, e as exclusões restritas a diretórios internos.
- O que mede
Presença da diretiva
Content-Signalnorobots.txt, declarando os usos permitidos do conteúdo.- O princípio
-
robots.txtresponde 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.
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
- 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.
| Check | Padrão | Pergunta que responde | Neste projeto |
|---|---|---|---|
apiCatalog |
RFC 9727 | Que APIs existem e onde está a especificação de cada uma? | /.well-known/api-catalog |
ard | Agent 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 |
authMd | auth.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 |
- 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.
{
"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" }
]
}
]
}
- 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.
{
"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.
- 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.mde 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.
{
"$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"
}
]
}
- 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.
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.
O agente não sabia que existiam recursos além das páginas
- 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: Acceptjunto. 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/markdowndevolve o companion.md; qualquer outro cliente recebe HTML.- Implementação
Função na borda (
infra/cloudfront-functions/viewer-request.js) comparando os valoresq, mais companions.mdgerados 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;Acceptde 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.
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
.htmlpassou 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.htmlali 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.
// `/.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-Signalnorobots.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.
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.mdpublicado; - 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.
- o bloco de autenticação de agente vive nos metadados do servidor de autorização, não no
- Implementação
public/.well-known/oauth-authorization-server, com o bloco no formato aceito, epublic/auth.mddescrevendo 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.
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": 0e"AD": true. OADé 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
AbortControllerpara 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.
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:
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.
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:
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".
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
- Corrija um check por vez. Duas correções no mesmo deploy e você não sabe qual funcionou.
- Publique. Um scan roda contra produção, não contra o seu repositório.
- Rescaneie e leia a evidência, não o texto de remediação.
- 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.
12 · Fontes
Referências
Fontes primárias. Onde existe RFC, a RFC é a referência — não o resumo dela.
Agent Readiness
RFCs
- RFC 8288 — Web Linking (header
Link) - RFC 9309 — Robots Exclusion Protocol
- RFC 9460 — registros SVCB e HTTPS
- RFC 7231 §5.3.2 — negociação de conteúdo (
Accept) - RFC 7763 — o tipo
text/markdown - RFC 9727 — API Catalog
- RFC 9728 — OAuth Protected Resource Metadata
- RFC 8414 — OAuth Authorization Server Metadata
- RFC 8615 — o prefixo
/.well-known/
Protocolos de agente
Neste site
- Engenharia de Agentes de IA — o MCP como fronteira de segurança do agente
- A Engenharia da Confiança — determinístico-primeiro e contratos rígidos
- O catálogo completo
- Esta página em Markdown — a versão sem layout
- llms.txt — o índice deste domínio para modelos
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.