Agent.reviews: Como Funciona a Plataforma de Avaliação por Agentes de IA

Em outubro de 2026, a Armature, uma startup do programa YC batch P26, lançou no Hacker News o agent.reviews, uma plataforma onde quem escreve e lê avaliações de software não é humano, mas sim agentes de código. O co-fundador Louis apresentou o projeto afirmando que a Armature já mediu mais de 50 mil sessões de agentes e percebeu que, repetidamente, agentes diferentes enfrentavam as mesmas limitações ao usar a mesma ferramenta, sem que isso fosse corrigido, devido à ausência de um loop de feedback entre agentes e fornecedores. A proposta é fechar esse loop. Este artigo explora como a plataforma funciona por baixo.

O que foi lançado, em uma frase

O agent.reviews é descrito pelos autores como o G2 para agentes, funcionando com um conjunto de skills e uma CLI npm (@armature-tech/agent-reviews) que conecta o agente aos endpoints da API, permitindo que Claude Code, Codex, Cursor e outros consigam checar reviews antes de escolher uma ferramenta e postar as próprias depois de usar. No lançamento, a Armature afirma que agentes já escreveram mais de 100 mil reviews de mais de 6 mil ferramentas após tarefas reais.

Como funciona por baixo

A camada 1: a skill

Para entender o mecanismo, é preciso compreender o que é uma skill. Pense em um funcionário novo que entra na empresa com uma pasta de procedimentos na mesa. Ele não decora tudo, apenas olha os títulos. Quando uma tarefa corresponde a um título, ele abre a pasta específica e segue o passo a passo. É exatamente isso que uma skill faz com o agente, mas de forma mais formalizada.

Agent Skills são um formato leve e aberto para estender capacidades de agentes com conhecimento e workflows especializados. No núcleo, uma skill é uma pasta contendo um arquivo SKILL.md com metadados (nome e descrição, no mínimo) e instruções que dizem ao agente como executar uma tarefa específica. O carregamento é feito em três estágios: na descoberta, no startup, o agente carrega apenas o nome e a descrição de cada skill disponível, suficiente para saber quando ela pode ser relevante; na ativação, quando uma tarefa corresponde à descrição de uma skill, o agente lê o SKILL.md completo para dentro do contexto; na execução, ele segue as instruções, opcionalmente rodando código embutido ou carregando arquivos referenciados conforme necessário.

Onde a analogia do funcionário com a pasta quebra: diferente de uma pessoa, o agente paga em tokens cada byte carregado no contexto, então essa carga tardia (progressive disclosure) não é só organização, é economia direta de custo e de ruído no raciocínio.

A skill do agent.reviews é publicada em https://agent.reviews/skill.md e o próprio site anuncia que toda página tem versão em Markdown no endereço + .md, listadas em llms.txt. Ou seja, o site foi construído com dois públicos em mente desde o começo, humanos no HTML e agentes nos arquivos .md estruturados.

A camada 2: a CLI que segura o token

A parte interessante do design está na CLI npm. O agente nunca toca credencial. Quem toca é o processo da CLI, que roda no computador do humano. Todo agente de código na máquina usa esse sign-in, e nenhum agente vê ou manipula o token.

O fluxo de autenticação é um device-code flow clássico: o comando abre um link de sign-in, você confere que a página mostra o mesmo código do terminal e aprova, e o comando salva o sign-in em ~/.armature/agent-review.json, legível apenas por você.

Daí para a frente, o agente invoca a CLI como se fosse qualquer outro comando de shell. A skill agent-review manda os reviews através do comando, e os agentes leem reviews através dele, para nunca ler o token: submit [arquivo] envia um review como JSON vindo de arquivo ou stdin e imprime a resposta como JSON; estando autenticado, o review publica verified na hora; caso contrário, a resposta carrega um link de sign-in para mostrar à pessoa e o review espera por ele, com reviews posteriores se juntando ao mesmo link; check coleta o sign-in depois que a pessoa aprovar o link e salva o token no arquivo imprimindo só o status.

Para leitura, read <tool> imprime o rating e os reviews de uma ferramenta como JSON, e read –category <categoria> lista as ferramentas de uma categoria por rating, com –sort, –agent, –outcome e –page afunilando como no site, exigindo o sign-in e pelo menos um review público dos agentes da pessoa, igual à leitura no agent.reviews. Isso é importante: ler custa escrever. Não é um site aberto para scraping, é um ecossistema de reciprocidade.

A camada 3: a sanitização antes de publicar

Agente de código vê de tudo. Prompt do usuário, chaves de API no .env, trechos de código proprietário, nomes de clientes. Deixar um agente escrever review em texto livre e publicar na web pública é receita para vazamento. A Armature trata isso com um pipeline de três camadas.

As reviews enviadas pelo agente podem conter informação sensível, então a Armature aplica três camadas de verificação antes de publicar: regras determinísticas para filtrar segredos, PII e URLs; o classificador Jev para procurar vazamentos que passaram pela checagem inicial; e um modelo de linguagem pequeno que revisa a review mais uma vez. Isso bate com o que a Armature diz publicamente: toda review é anonimizada e não contém PII, nem código, nem prompts, nem dados pessoais, com o Jev da typesafeai rodando em escala com checks determinísticos e de LLM por cima.

Além disso, o nome do dono do computador nunca aparece. O que aparece é qual agente escreveu (Claude Code, Codex, Cursor, Muse Code, etc.) e o conteúdo da review. Ao submeter uma review, o agente registra as tarefas que realmente executou, como conectou as ferramentas, e os resultados dessas tarefas, com três critérios de avaliação (usefulness, ease of use, reliability) cada um pontuado de 1 a 5.

Juntando tudo: a sequência completa

1. O humano roda npx @armature-tech/agent-reviews login e autentica o device.
2. A skill fica disponível para o agente (seja via SKILL.md local, seja referenciada por skill.md remoto).
3. Quando o agente vai escolher uma ferramenta (ex.: um banco), ele ativa a skill, que o instrui a chamar read na CLI, que bate na API e devolve JSON.
4. Depois de executar a tarefa, a skill o instrui a chamar submit com um JSON descrevendo o que fez e os três scores.
5. O backend passa o payload pelos filtros determinísticos, pelo Jev, pelo LLM pequeno, remove nome e dado identificável e publica.

O que isso significa na prática

Para quem vive dentro de agente de código todos os dias, isso é uma peça de infraestrutura, não um site de notícia. Trabalhando com agente de código todo dia, com arquivo de contexto em cada repositório, uma coisa fica evidente: o arquivo existe para o agente herdar as decisões do projeto em vez de redescobrir mal a cada sessão. O agent.reviews propõe o mesmo princípio, só que em escala coletiva: em vez de cada agente redescobrir sozinho que a documentação do Cursor está espalhada ou que a instalação do Daytona exige um certo truque, uma review verified fica registrada e o próximo agente lê antes de começar.

Um exemplo de payload de review (inferido do padrão da CLI, formato JSON passado para submit):

{
 "tool": "redis",
 "scores": {
 "usefulness": 4,
 "ease_of_use": 4,
 "reliability": 5
 },
 "outcome": "success",
 "summary": "Point-lookup usado como source of truth; busca de staff movida para inverted index para evitar scan do keyspace.",
 "agent": "muse-code"
}

E para ler a categoria:

npx @armature-tech/agent-reviews read --category databases --sort rating

Isso devolve JSON, não HTML. Faz diferença porque o agente consome o resultado sem precisar parsear página renderizada, o que corta um passo (e tokens) do loop.

Onde quebra

Primeiro ponto: reviews escritas por agente são tão boas quanto a sessão em que o agente estava. Um agente que executou mal uma tarefa pode culpar a ferramenta por limitação própria. Não há (ao menos documentado) uma ponderação por qualidade da sessão, só o filtro de verified vs não verified via login. Isso é diferente da G2 humana, onde o reviewer pelo menos sabe se o próprio uso foi ruim.

Segundo: o modelo cobra reciprocidade. Ler precisa do sign-in e de pelo menos uma review pública dos agentes da pessoa, igual à leitura no agent.reviews. Para quem usa agente em contexto sensível (código fechado, cliente regulado), publicar qualquer review, mesmo filtrada, pode ser inaceitável por política interna. Nesse caso, a plataforma não é consultável.

Terceiro: o pipeline de sanitização de três camadas é bom, mas não é mágico. Filtro determinístico pega padrões conhecidos (chaves AWS, emails, URLs), classificador pega categorias previstas, LLM pequeno pega o resto que couber na janela. Nenhum dos três pega semântica combinada do tipo “estratégia de pricing descrita em prosa que denuncia o cliente sem citar o nome”. Em dado sensível, o custo de um falso negativo é alto.

Quarto, e talvez mais prático: escrever sobre algo obriga a entender a ponta que a prática deixa passar, e nos livros que escrevi, entre eles a série IA na Prática, isso aparece com força em context engineering. Review escrita por agente é, no fim, um pedaço de contexto curto que será injetado no raciocínio de outro agente. Contexto demais degrada o raciocínio e multiplica custo ao mesmo tempo. Contexto curado ganha de janela grande. Se o agent.reviews virar um dump de milhões de reviews não resumidas, a leitura começa a atrapalhar mais do que ajuda. A qualidade da agregação (média, cluster, highlights) é o que define se isso escala como fonte útil ou vira ruído.

O que não dá para afirmar ainda

Alguns pontos ficaram em aberto na documentação pública:

• Como exatamente a Armature pondera a nota média. No momento em que a GIGAZINE escreveu, havia 1749 reviews postadas e a nota geral era 4.2, enquanto o próprio lançamento fala em 100 mil reviews. Os números batem com janelas de tempo diferentes, mas o critério de agregação por ferramenta não está detalhado.
• Como o site evita gaming. Se eu rodo mil agentes meus escrevendo review positiva da minha própria ferramenta, o que impede? Verified via device é uma barreira, não uma garantia.
• Como vendors respondem. A promessa é fechar o loop entre agente e vendor, mas nada no material público mostra o canal de resposta do vendor dentro da plataforma.
• O custo real de rodar o pipeline em escala, e se a leitura ficará gratuita indefinidamente.

Como testar isso você mesmo

Caminho curto, 10 minutos, assumindo que você já usa Claude Code, Codex ou Cursor:

1. No terminal, rode npx @armature-tech/agent-reviews login e aprove no browser.
2. Peça ao seu agente para ler https://agent.reviews/install.md e seguir os passos de setup da skill.
3. Em um repositório qualquer, peça ao agente: “antes de escolher a biblioteca X para esta tarefa, consulte agent.reviews na categoria correspondente e me mostre o top 3 com os pontos fracos citados”.
4. Depois de concluir uma tarefa real com alguma ferramenta, peça: “escreva uma review honesta no agent.reviews sobre a ferramenta Y com base no que acabamos de fazer”. O agente deve chamar submit e devolver o JSON de resposta.
5. Confira o review publicado no site. Veja o que foi mantido, o que foi removido pelo filtro, e se o seu nome ou qualquer detalhe do projeto vazou. Esse é o teste que importa.

Se o passo 5 passar sem susto, o pipeline cumpre o que promete. Se vazar algo, você acabou de encontrar o caso para o qual os três filtros não bastaram, e essa é informação mais útil do que qualquer review que você vai ler lá dentro.