A afirmação: um agente de IA que nunca ouviu falar de AX consegue descobrir, aprender e falar a linguagem-máquina deste site numa só conversa — sem SDK, sem documentação, sem chave de API.
Não acredite na nossa palavra. Cole o prompt abaixo em qualquer agente capaz de obter URL — ChatGPT, Claude, Gemini ou o seu — e observe.
Fetch https://rainz.ai/llms.txt and read the "For AI agents" section at the end. Then execute what it teaches, zero-shot: 1. GET https://rainz.ai/wp-json/ax/v1/x?s=ax1+q.svc.pr+n%3D3 and show the raw reply. 2. Decode the reply using only the protocol's own hints. 3. Follow the nxu URL from the reply (GET, show raw). If your browsing tool refuses a URL it found inside a page, print that URL and ask me to paste it back to you — a URL in my message will pass. 4. If an nxx referral to another site appears, do the same with it. GET requests only — do not POST anything. Finally report: every URL you fetched, each raw response, and anything that confused you.
O agente recebe uma resposta em texto simples como esta — ofertas, disponibilidade e ações seguintes num só GET, cerca de 80 % menos tokens do que o rastreio JSON equivalente:
ax1 ok op=o n=3 cov=1 cb=2 nx="a.quote i=<sku>; a.lead @ POST …/intent" nxu=… nxx=… =i:of-1|t:"AI implementation for business"|pr:quote|av:available|u:https://rainz.ai/ …
Depois descodifica cada campo corretamente — porque o protocolo ensina a sua própria sintaxe: uma consulta mal formada devolve um exemplo resolvido, o cabeçalho da resposta indica cov= (que parte da sua consulta foi compreendida) e cada resposta transporta o passo seguinte sob a forma de um URL literal.
Alguns agentes alojados (entre eles o navegador do ChatGPT) recusam-se a abrir qualquer URL descoberto dentro de uma página obtida — uma regra de segurança sobre proveniência, independentemente do próprio URL. O protocolo degrada-se com elegância: o agente mostra-lhe o URL do passo seguinte, o utilizador volta a colá-lo e a cadeia continua. Os agentes com acesso HTTP real (Claude, agentes via API, rastreadores, clientes MCP) percorrem toda a cadeia sozinhos.
https://rainz.ai/wp-json/rainz-axs/v1/mcpcurl "https://rainz.ai/wp-json/ax/v1/x?s=ax1+q.svc.pr+n%3D3"O seu agente passou no teste? Diga-nos — envie um contacto através do próprio protocolo: é a ação a.lead que o seu agente acabou de aprender.
O desafio zero-shot não é um teste ao agente. É um teste ao protocolo e ao site que o implementa. A um agente que nunca encontrou AX é dada uma tarefa e nada mais: ou a especificação é suficientemente autodescritiva para que ele consiga, ou não é. Este enquadramento importa, porque significa que uma falha é informação sobre o desenho e não um veredicto sobre o modelo.
Há três coisas em observação. Consegue o agente encontrar o ponto de entrada sem que lhe digam onde está? Depois de ter o manifesto, consegue deduzir a estrutura sem documentação externa? E consegue completar a tarefa de ponta a ponta sem que um humano esclareça seja o que for a meio? Um protocolo que precisa de um tutorial para ser utilizável falhou exatamente naquilo para que existe.
As normas são habitualmente avaliadas perguntando se um engenheiro competente as consegue implementar a partir do documento. Esse teste é demasiado generoso para um protocolo cujos consumidores são agentes. Um agente que chega ao seu site não leu a especificação, não conhece as suas convenções e não lhe fará qualquer pergunta de esclarecimento. Tem uma única passagem pelo material e, se o material for ambíguo, vai adivinhar.
O desempenho zero-shot é por isso a aproximação mais próxima das condições reais. Tem também um efeito secundário útil: como a fasquia é alta, expõe exatamente o tipo de conhecimento implícito em que os autores das especificações não reparam que estão a assentar. Cada ponto em que um agente tropeça é um ponto onde o documento assumiu algo que nunca declarou.
Pode reproduzir isto no seu próprio site em poucos minutos. Abra uma conversa nova com qualquer modelo capaz, dê-lhe apenas o seu domínio e uma tarefa que um cliente real pudesse ter, e veja para onde vai. Não ajude. Não corrija. O valor está inteiramente em observar o primeiro ponto em que erra.
Use uma conversa nova de cada vez, porque um modelo que já foi corrigido uma vez deixou de estar em zero-shot. E varie a tarefa: um agente a quem se pede que resuma o que faz vai exercitar partes do site completamente diferentes de outro a quem se pede que encontre os seus preços ou verifique se serve determinado mercado.
O erro comum é tratar a pontuação como uma nota. O número importa muito menos do que a questão de saber onde exatamente o agente parou. Um agente que descobre o manifesto mas lê mal a estrutura dos serviços está a dizer-lhe algo completamente diferente de outro que nunca chegou a encontrar o ponto de entrada. O primeiro é um problema de redação, o segundo um problema de descoberta, e as correções não têm nada em comum.
Tenha também presente que o resultado depende do modelo que executa o teste. Modelos diferentes chegam com conhecimento prévio diferente, e um agente que encontra o protocolo pela primeira vez comporta-se de forma distinta de outro que já viu estruturas semelhantes. A comparação significativa não é, portanto, entre o seu site e o de outra pessoa, mas entre o seu site hoje e o seu site no mês passado, no mesmo modelo e com o mesmo prompt.
O exercício só compensa o tempo investido se produzir uma lista de ações. Registe o ponto exato em que o agente falhou, mude uma coisa e volte a executar. Mudar várias coisas ao mesmo tempo pode melhorar a pontuação mas não lhe dirá o que causou a melhoria. Três ou quatro iterações chegam normalmente para levar um site de um estado em que os agentes se confundem para outro em que completam a tarefa à primeira — que é, no fim, o único resultado que conta comercialmente.
Uma execução que termina em falha é mais útil do que uma bem-sucedida, desde que registe onde parou. As falhas agrupam-se em quatro tipos. As falhas de descoberta significam que o agente nunca encontrou um ponto de entrada — o manifesto está em falta, mal colocado ou bloqueado. As falhas de compreensão significam que encontrou o manifesto mas não conseguiu perceber o que os campos queriam dizer, o que aponta para a nomenclatura e não para a estrutura. As falhas de navegação significam que percebeu a estrutura mas não conseguiu chegar ao conteúdo, normalmente porque uma página ligada redireciona ou exige execução de scripts. As falhas de conclusão significam que obteve tudo e ainda assim produziu a resposta errada, o que é quase sempre um problema de conteúdo e não de protocolo.
Classifique a falha antes de mudar seja o que for. O instinto de corrigir a última coisa que viu correr mal é forte e normalmente mal dirigido: um agente que dá uma resposta errada no passo quatro fê-lo muitas vezes por causa de uma ambiguidade introduzida no passo um.