{"id":767,"date":"2026-10-08T18:33:44","date_gmt":"2026-10-08T21:33:44","guid":{"rendered":"https:\/\/yellowkode.com\/blog\/agent-reviews-como-funciona\/"},"modified":"2026-10-08T18:33:44","modified_gmt":"2026-10-08T21:33:44","slug":"agent-reviews-como-funciona","status":"publish","type":"post","link":"https:\/\/yellowkode.com\/blog\/agent-reviews-como-funciona\/","title":{"rendered":"Agent.reviews: Como Funciona a Plataforma de Avalia\u00e7\u00e3o por Agentes de IA"},"content":{"rendered":"

Em outubro de 2026, a Armature, uma startup do programa YC batch P26, lan\u00e7ou no Hacker News o agent.reviews<\/strong>, uma plataforma onde quem escreve e l\u00ea avalia\u00e7\u00f5es de software n\u00e3o \u00e9 humano, mas sim agentes de c\u00f3digo. O co-fundador Louis apresentou o projeto afirmando que a Armature j\u00e1 mediu mais de 50 mil sess\u00f5es de agentes e percebeu que, repetidamente, agentes diferentes enfrentavam as mesmas limita\u00e7\u00f5es ao usar a mesma ferramenta, sem que isso fosse corrigido, devido \u00e0 aus\u00eancia de um loop de feedback entre agentes e fornecedores. A proposta \u00e9 fechar esse loop. Este artigo explora como a plataforma funciona por baixo.<\/p>\n

O que foi lan\u00e7ado, em uma frase<\/h2>\n

O agent.reviews \u00e9 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\u00f3prias depois de usar. No lan\u00e7amento, a Armature afirma que agentes j\u00e1 escreveram mais de 100 mil reviews de mais de 6 mil ferramentas ap\u00f3s tarefas reais.<\/p>\n

Como funciona por baixo<\/h2>\n

A camada 1: a skill<\/h3>\n

Para entender o mecanismo, \u00e9 preciso compreender o que \u00e9 uma skill. Pense em um funcion\u00e1rio novo que entra na empresa com uma pasta de procedimentos na mesa. Ele n\u00e3o decora tudo, apenas olha os t\u00edtulos. Quando uma tarefa corresponde a um t\u00edtulo, ele abre a pasta espec\u00edfica e segue o passo a passo. \u00c9 exatamente isso que uma skill faz com o agente, mas de forma mais formalizada.<\/p>\n

Agent Skills s\u00e3o um formato leve e aberto para estender capacidades de agentes com conhecimento e workflows especializados. No n\u00facleo, uma skill \u00e9 uma pasta contendo um arquivo SKILL.md com metadados (nome e descri\u00e7\u00e3o, no m\u00ednimo) e instru\u00e7\u00f5es que dizem ao agente como executar uma tarefa espec\u00edfica. O carregamento \u00e9 feito em tr\u00eas est\u00e1gios: na descoberta, no startup, o agente carrega apenas o nome e a descri\u00e7\u00e3o de cada skill dispon\u00edvel, suficiente para saber quando ela pode ser relevante; na ativa\u00e7\u00e3o, quando uma tarefa corresponde \u00e0 descri\u00e7\u00e3o de uma skill, o agente l\u00ea o SKILL.md completo para dentro do contexto; na execu\u00e7\u00e3o, ele segue as instru\u00e7\u00f5es, opcionalmente rodando c\u00f3digo embutido ou carregando arquivos referenciados conforme necess\u00e1rio.<\/p>\n

Onde a analogia do funcion\u00e1rio com a pasta quebra: diferente de uma pessoa, o agente paga em tokens cada byte carregado no contexto, ent\u00e3o essa carga tardia (progressive disclosure) n\u00e3o \u00e9 s\u00f3 organiza\u00e7\u00e3o, \u00e9 economia direta de custo e de ru\u00eddo no racioc\u00ednio.<\/p>\n

A skill do agent.reviews \u00e9 publicada em https:\/\/agent.reviews\/skill.md<\/code> e o pr\u00f3prio site anuncia que toda p\u00e1gina tem vers\u00e3o em Markdown no endere\u00e7o + .md<\/code>, listadas em llms.txt<\/code>. Ou seja, o site foi constru\u00eddo com dois p\u00fablicos em mente desde o come\u00e7o, humanos no HTML e agentes nos arquivos .md estruturados.<\/p>\n

A camada 2: a CLI que segura o token<\/h3>\n

A parte interessante do design est\u00e1 na CLI npm. O agente nunca toca credencial. Quem toca \u00e9 o processo da CLI, que roda no computador do humano. Todo agente de c\u00f3digo na m\u00e1quina usa esse sign-in, e nenhum agente v\u00ea ou manipula o token.<\/p>\n

O fluxo de autentica\u00e7\u00e3o \u00e9 um device-code flow cl\u00e1ssico: o comando abre um link de sign-in, voc\u00ea confere que a p\u00e1gina mostra o mesmo c\u00f3digo do terminal e aprova, e o comando salva o sign-in em ~\/.armature\/agent-review.json, leg\u00edvel apenas por voc\u00ea.<\/p>\n

Da\u00ed para a frente, o agente invoca a CLI como se fosse qualquer outro comando de shell. A skill agent-review manda os reviews atrav\u00e9s do comando, e os agentes leem reviews atrav\u00e9s 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\u00e1rio, a resposta carrega um link de sign-in para mostrar \u00e0 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\u00f3 o status.<\/p>\n

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\u00fablico dos agentes da pessoa, igual \u00e0 leitura no agent.reviews. Isso \u00e9 importante: ler custa escrever. N\u00e3o \u00e9 um site aberto para scraping, \u00e9 um ecossistema de reciprocidade.<\/p>\n

A camada 3: a sanitiza\u00e7\u00e3o antes de publicar<\/h3>\n

Agente de c\u00f3digo v\u00ea de tudo. Prompt do usu\u00e1rio, chaves de API no .env, trechos de c\u00f3digo propriet\u00e1rio, nomes de clientes. Deixar um agente escrever review em texto livre e publicar na web p\u00fablica \u00e9 receita para vazamento. A Armature trata isso com um pipeline de tr\u00eas camadas.<\/p>\n

As reviews enviadas pelo agente podem conter informa\u00e7\u00e3o sens\u00edvel, ent\u00e3o a Armature aplica tr\u00eas camadas de verifica\u00e7\u00e3o antes de publicar: regras determin\u00edsticas 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 \u00e9 anonimizada e n\u00e3o cont\u00e9m PII, nem c\u00f3digo, nem prompts, nem dados pessoais, com o Jev da typesafeai rodando em escala com checks determin\u00edsticos e de LLM por cima.<\/p>\n

Al\u00e9m disso, o nome do dono do computador nunca aparece. O que aparece \u00e9 qual agente escreveu (Claude Code, Codex, Cursor, Muse Code, etc.) e o conte\u00fado 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\u00eas crit\u00e9rios de avalia\u00e7\u00e3o (usefulness, ease of use, reliability) cada um pontuado de 1 a 5.<\/p>\n

Juntando tudo: a sequ\u00eancia completa<\/h3>\n
    \n
  1. O humano roda npx @armature-tech\/agent-reviews login<\/code> e autentica o device.<\/li>\n
  2. A skill fica dispon\u00edvel para o agente (seja via SKILL.md local, seja referenciada por skill.md remoto).<\/li>\n
  3. Quando o agente vai escolher uma ferramenta (ex.: um banco), ele ativa a skill, que o instrui a chamar read<\/code> na CLI, que bate na API e devolve JSON.<\/li>\n
  4. Depois de executar a tarefa, a skill o instrui a chamar submit<\/code> com um JSON descrevendo o que fez e os tr\u00eas scores.<\/li>\n
  5. O backend passa o payload pelos filtros determin\u00edsticos, pelo Jev, pelo LLM pequeno, remove nome e dado identific\u00e1vel e publica.<\/li>\n<\/ol>\n

    O que isso significa na pr\u00e1tica<\/h2>\n

    Para quem vive dentro de agente de c\u00f3digo todos os dias, isso \u00e9 uma pe\u00e7a de infraestrutura, n\u00e3o um site de not\u00edcia. Trabalhando com agente de c\u00f3digo todo dia, com arquivo de contexto em cada reposit\u00f3rio, uma coisa fica evidente: o arquivo existe para o agente herdar as decis\u00f5es do projeto em vez de redescobrir mal a cada sess\u00e3o. O agent.reviews prop\u00f5e o mesmo princ\u00edpio, s\u00f3 que em escala coletiva: em vez de cada agente redescobrir sozinho que a documenta\u00e7\u00e3o do Cursor est\u00e1 espalhada ou que a instala\u00e7\u00e3o do Daytona exige um certo truque, uma review verified fica registrada e o pr\u00f3ximo agente l\u00ea antes de come\u00e7ar.<\/p>\n

    Um exemplo de payload de review (inferido do padr\u00e3o da CLI, formato JSON passado para submit<\/code>):<\/p>\n

    {\n \"tool\": \"redis\",\n \"scores\": {\n \"usefulness\": 4,\n \"ease_of_use\": 4,\n \"reliability\": 5\n },\n \"outcome\": \"success\",\n \"summary\": \"Point-lookup usado como source of truth; busca de staff movida para inverted index para evitar scan do keyspace.\",\n \"agent\": \"muse-code\"\n}\n<\/code><\/pre>\n
    E para ler a categoria:<\/p>\n
    npx @armature-tech\/agent-reviews read --category databases --sort rating\n<\/code><\/pre>\n
    Isso devolve JSON, n\u00e3o HTML. Faz diferen\u00e7a porque o agente consome o resultado sem precisar parsear p\u00e1gina renderizada, o que corta um passo (e tokens) do loop.<\/p>\n
    Onde quebra<\/h2>\n
    Primeiro ponto: reviews escritas por agente s\u00e3o t\u00e3o boas quanto a sess\u00e3o em que o agente estava. Um agente que executou mal uma tarefa pode culpar a ferramenta por limita\u00e7\u00e3o pr\u00f3pria. N\u00e3o h\u00e1 (ao menos documentado) uma pondera\u00e7\u00e3o por qualidade da sess\u00e3o, s\u00f3 o filtro de verified vs n\u00e3o verified via login. Isso \u00e9 diferente da G2 humana, onde o reviewer pelo menos sabe se o pr\u00f3prio uso foi ruim.<\/p>\n
    Segundo: o modelo cobra reciprocidade. Ler precisa do sign-in e de pelo menos uma review p\u00fablica dos agentes da pessoa, igual \u00e0 leitura no agent.reviews. Para quem usa agente em contexto sens\u00edvel (c\u00f3digo fechado, cliente regulado), publicar qualquer review, mesmo filtrada, pode ser inaceit\u00e1vel por pol\u00edtica interna. Nesse caso, a plataforma n\u00e3o \u00e9 consult\u00e1vel.<\/p>\n
    Terceiro: o pipeline de sanitiza\u00e7\u00e3o de tr\u00eas camadas \u00e9 bom, mas n\u00e3o \u00e9 m\u00e1gico. Filtro determin\u00edstico pega padr\u00f5es conhecidos (chaves AWS, emails, URLs), classificador pega categorias previstas, LLM pequeno pega o resto que couber na janela. Nenhum dos tr\u00eas pega sem\u00e2ntica combinada do tipo “estrat\u00e9gia de pricing descrita em prosa que denuncia o cliente sem citar o nome”. Em dado sens\u00edvel, o custo de um falso negativo \u00e9 alto.<\/p>\n
    Quarto, e talvez mais pr\u00e1tico: escrever sobre algo obriga a entender a ponta que a pr\u00e1tica deixa passar, e nos livros que escrevi, entre eles a s\u00e9rie IA na Pr\u00e1tica, isso aparece com for\u00e7a em context engineering. Review escrita por agente \u00e9, no fim, um peda\u00e7o de contexto curto que ser\u00e1 injetado no racioc\u00ednio de outro agente. Contexto demais degrada o racioc\u00ednio e multiplica custo ao mesmo tempo. Contexto curado ganha de janela grande. Se o agent.reviews virar um dump de milh\u00f5es de reviews n\u00e3o resumidas, a leitura come\u00e7a a atrapalhar mais do que ajuda. A qualidade da agrega\u00e7\u00e3o (m\u00e9dia, cluster, highlights) \u00e9 o que define se isso escala como fonte \u00fatil ou vira ru\u00eddo.<\/p>\n
    O que n\u00e3o d\u00e1 para afirmar ainda<\/h2>\n
    Alguns pontos ficaram em aberto na documenta\u00e7\u00e3o p\u00fablica:<\/p>\n
      \n
    • Como exatamente a Armature pondera a nota m\u00e9dia. No momento em que a GIGAZINE escreveu, havia 1749 reviews postadas e a nota geral era 4.2, enquanto o pr\u00f3prio lan\u00e7amento fala em 100 mil reviews. Os n\u00fameros batem com janelas de tempo diferentes, mas o crit\u00e9rio de agrega\u00e7\u00e3o por ferramenta n\u00e3o est\u00e1 detalhado.<\/li>\n
    • Como o site evita gaming. Se eu rodo mil agentes meus escrevendo review positiva da minha pr\u00f3pria ferramenta, o que impede? Verified via device \u00e9 uma barreira, n\u00e3o uma garantia.<\/li>\n
    • Como vendors respondem. A promessa \u00e9 fechar o loop entre agente e vendor, mas nada no material p\u00fablico mostra o canal de resposta do vendor dentro da plataforma.<\/li>\n
    • O custo real de rodar o pipeline em escala, e se a leitura ficar\u00e1 gratuita indefinidamente.<\/li>\n<\/ul>\n
      Como testar isso voc\u00ea mesmo<\/h2>\n
      Caminho curto, 10 minutos, assumindo que voc\u00ea j\u00e1 usa Claude Code, Codex ou Cursor:<\/p>\n
        \n
      1. No terminal, rode npx @armature-tech\/agent-reviews login<\/code> e aprove no browser.<\/li>\n
      2. Pe\u00e7a ao seu agente para ler https:\/\/agent.reviews\/install.md<\/code> e seguir os passos de setup da skill.<\/li>\n
      3. Em um reposit\u00f3rio qualquer, pe\u00e7a 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”.<\/li>\n
      4. Depois de concluir uma tarefa real com alguma ferramenta, pe\u00e7a: “escreva uma review honesta no agent.reviews sobre a ferramenta Y com base no que acabamos de fazer”. O agente deve chamar submit<\/code> e devolver o JSON de resposta.<\/li>\n
      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 \u00e9 o teste que importa.<\/li>\n<\/ol>\n
        Se o passo 5 passar sem susto, o pipeline cumpre o que promete. Se vazar algo, voc\u00ea acabou de encontrar o caso para o qual os tr\u00eas filtros n\u00e3o bastaram, e essa \u00e9 informa\u00e7\u00e3o mais \u00fatil do que qualquer review que voc\u00ea vai ler l\u00e1 dentro.<\/p>\n","protected":false},"excerpt":{"rendered":"
        Como o agent.reviews funciona: skill, CLI, pipeline de sanitiza\u00e7\u00e3o de PII e como agentes leem e escrevem reviews de ferramentas.<\/p>\n","protected":false},"author":2,"featured_media":766,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-767","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/posts\/767","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/comments?post=767"}],"version-history":[{"count":0,"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/posts\/767\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/media\/766"}],"wp:attachment":[{"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/media?parent=767"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/categories?post=767"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/tags?post=767"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}