Um quadro de feedback para agentes de IA: deixe seus usuários escreverem o prompt

Um usuário te escreve às 23h. "O botão de exportar não faz nada no Safari."

Você sabe o que vem depois, porque isso já aconteceu cem vezes. Você lê. Você entende. Aí você abre um rastreador de issues e digita de novo, com suas palavras, com os caminhos dos arquivos, os passos para reproduzir e o contexto que o usuário não tinha. Depois, mais tarde, você abre um terminal e digita uma terceira vez, como prompt.

Três escritas do mesmo pedido. A primeira foi de graça e veio de quem realmente esbarrou no bug. As outras duas são suas.

Essa segunda e essa terceira escrita são a parte do trabalho que os agentes tornaram absurda.

A última coisa que você ainda digita à mão

Agentes de código eliminaram bastante digitação. Eles não eliminaram o briefing. Alguma coisa ainda precisa dizer ao agente o que construir, com detalhe suficiente para ele não adivinhar, e essa alguma coisa continua sendo um humano sentado num teclado convertendo as palavras dos outros em instruções.

Só que essa conversão quase sempre é inútil. Um bom relato de bug já contém o que um agente precisa: o que se esperava, o que aconteceu, em qual página, em qual navegador. Um bom pedido de funcionalidade já traz a intenção e o motivo. Quem escreveu estava mais perto do problema do que você.

Em vez disso, tratamos esse texto como matéria-prima a ser reprocessada, porque a ferramenta que coletou e a ferramenta que executa nunca foram a mesma. O feedback mora num produto, os tickets em outro, e o agente roda num terminal que não conhece nenhum dos dois.

Elimine essa distância e a etapa de reescrita não tem mais onde acontecer.

O que um quadro de feedback vira quando o quadro sabe executar

Um backlog público é uma página que seus usuários conseguem acessar. Eles reportam um bug, pedem uma funcionalidade, votam no que outra pessoa pediu, acompanham uma discussão e veem um status mudar. Até aqui, isso é um quadro de feedback, e existem bons quadros de feedback.

A diferença está em onde o ticket cai. Ele não cai num produto de feedback esperando ser exportado. Ele cai no quadro de tarefas de onde seus agentes já partem, como um ticket de primeira classe, ao lado dos que você mesmo escreveu.

A partir daí, mover o ticket para In Progress inicia um agente cujo briefing é o próprio ticket: o título, a descrição nas palavras de quem reportou, a página em que a pessoa estava, o navegador que ela usava e a conversa que vocês tiveram desde então. Ninguém reescreveu nada. O prompt é o relato.

A consequência interessante não é velocidade. É que quem descreveu o problema passou a ser quem especificou o trabalho, que é exatamente o que todo mundo diz querer do feedback dos usuários e quase ninguém organiza para acontecer. Essa inversão tem nome: é um backlog conduzido pelo cliente. A fila deixa de ser seu palpite sobre o que importa e vira um registro do que foi realmente pedido.

Três portas, porque as pessoas reportam de onde estão

Um quadro de feedback só funciona se reportar custar menos do que reclamar em outro lugar. Isso significa encontrar as pessoas onde o problema aconteceu.

A página pública é a porta óbvia: uma URL que você compartilha, com uma lista ou uma visão de roadmap, votos e um formulário. Funciona para um produto com usuários que vão salvar o link, e ainda serve como prova visível de que o trabalho está andando, o que vale mais do que um e-mail de status que ninguém lê.

O widget incorporável é a segunda: um pequeno script no seu próprio site que abre um formulário ali mesmo. A pessoa nunca sai da página em que o bug está, que é justamente o momento em que ela mais tem disposição para descrevê-lo.

A extensão do Chrome é a terceira, e é a que mais muda o comportamento. Seu usuário seleciona o texto quebrado em qualquer página, clica na extensão, e o ticket é aberto com a URL e a seleção já anexadas. O que chega até você não é "não funciona", é um relato com coordenadas.

Para uma agência, a terceira porta em geral é o próprio cliente, e o modo portal do cliente é só por convite: um quadro por cliente, ninguém mais enxerga, nenhuma assinatura de SaaS a mais na pilha.

Roteamento, porque "o agente certo" não é um agente só

Um ticket que chega não está endereçado a ninguém. Esse é o problema prático de qualquer caixa de entrada: alguém precisa decidir quem assume.

Os tickets que vêm de fora são roteados para o agente cuja especialidade combina, então um layout quebrado vai para um especialista de frontend e uma query que vaza vai para um de backend, sem você triar a fila na mão toda manhã. Quando nada está configurado, o comportamento padrão é deliberadamente burro e previsível: o primeiro agente de desenvolvimento do projeto, nunca um papel de marketing ou de PM que por acaso esteja no topo da lista.

Você também pode direcionar um ticket para uma equipe de agentes inteira em vez de um único agente, para que um pedido de cliente passe por uma etapa de dev e depois por uma etapa de QA antes de chegar até você.

A parte que todo mundo esquece: o que volta para quem reportou

Coletar feedback é fácil. É no fechamento do ciclo que os produtos perdem as pessoas.

Quando um ticket entra em desenvolvimento, quem escreveu é avisado. Quando ele é priorizado, é avisado. Quando você decide que não vai fazer, é avisado também, com o motivo que você escreveu, o que é bem melhor do que silêncio. E quando a correção realmente entra no ar, a pessoa recebe uma mensagem dizendo isso, agrupada em uma notificação por release em vez de cinco e-mails separados para cinco tickets.

Tem um detalhe menor que importa mais do que parece: o commit que fecha um ticket de usuário credita quem reportou pelo primeiro nome, e esse crédito sobrevive até o changelog público. Quem vê o próprio nome ligado a uma mudança entregue reporta o próximo bug também. Esse é todo o mecanismo de retenção, e ele não custa nada. Rode esse ciclo por alguns meses e você obtém desenvolvimento guiado por feedback como fato observável, não como slogan: os votos decidem a ordem, e a ordem decide as releases.

Se um pedido chega vago, a delimitação de tickets fica entre o relato e o trabalho: um agente Product Manager transforma o pedido nebuloso num mockup do seu produto real com a mudança aplicada, para você validar a ideia no próprio ticket antes de uma linha de código ser escrita.

Onde as ferramentas clássicas param

Isso não é uma alfinetada nos incumbentes. Canny, Featurebase, Fider e UserVoice fazem bem a coleta, a deduplicação e o ranqueamento, e têm anos de refinamento nas partes que importam para times de produto. Todos param no mesmo ponto pelo mesmo motivo estrutural: foram feitos para organizações em que engenharia é outro departamento, alcançável só por meio de uma exportação.

A última linha é a que decide. Num time grande, transformar um pedido em especificação é um trabalho de verdade com valor de verdade, e a exportação não é o gargalo. Num time de uma a cinco pessoas entregando com agentes de código, essa reescrita é o gargalo, e é perda pura.

O que isso não resolve

Um quadro de feedback ligado aos agentes não é piloto automático, e tratá-lo como tal produz exatamente o que você imagina.

Tickets ruins continuam produzindo trabalho ruim. Um relato de uma linha sem caminho de reprodução não dá nada ao agente, e ele vai fazer alguma coisa errada com toda a confiança do mundo. O quadro só consegue repassar o que foi escrito.

Nada é mesclado sozinho. Um agente produz um branch e um diff, e toda regra que você tinha sobre revisar saída de agente continua valendo, principalmente em qualquer coisa que toque em autenticação, pagamentos ou dados. Um ticket vindo de um desconhecido não é motivo para baixar essa régua. É motivo para levantá-la.

E o volume é real. Um quadro público que dá certo fica barulhento, o que é um bom problema com um custo real. Duplicatas são sinalizadas no momento do envio, os votos separam o que uma pessoa queria do que quarenta pessoas queriam, e fechar um ticket com um motivo escrito é mais rápido do que deixá-lo apodrecer. Mas alguém ainda lê a caixa de entrada.

Como colocar no ar

Abra o backlog de um projeto, clique em Public backlog, escolha uma URL e um modo de visibilidade. Essa é toda a configuração, e a página já está no ar.

O que você faz depois importa mais do que a configuração. Coloque o link onde seus usuários já estão: dentro do app, nas suas respostas de suporte, no rodapé das suas notas de versão. Um quadro de feedback que ninguém conhece não coleta nada, e o modo de falha desta funcionalidade não é técnico: é o link nunca ser compartilhado.

O AgentsRoom é o centro de comando em que isso roda: um quadro de tarefas em que um card vira um agente rodando, uma página de feedback pública ou privada ligada a ele, um widget incorporável, uma extensão do Chrome e notificações para o cliente que disparam quando o trabalho realmente entra no ar. Funciona com Claude Code, Codex, OpenCode, Antigravity CLI, Aider, Grok Build, Mistral Vibe e Kimi Code.

Baixe o AgentsRoom e publique seu primeiro quadro.

Perguntas frequentes

O que é um quadro de feedback para agentes de IA?

Uma página pública em que os usuários reportam bugs e pedem funcionalidades, ligada ao mesmo quadro de tarefas de onde seus agentes de código executam. A diferença para uma ferramenta de feedback clássica está na última etapa: em vez de exportar o pedido para um rastreador de issues e reescrevê-lo como prompt, o próprio ticket vira o briefing do agente, nas palavras de quem reportou.

Um ticket de usuário consegue mesmo iniciar um agente de IA sozinho?

Iniciar continua sendo um ato deliberado: alguém move o ticket para In Progress e o agente sobe com o ticket como prompt. O que é automático é o roteamento, que manda um ticket recebido para o agente cuja especialidade combina com ele. Execução automática de tudo o que um desconhecido escreve não é funcionalidade, é falha de segurança.

Qual é a diferença para Canny, Featurebase, Fider ou UserVoice?

Essas ferramentas são excelentes em coletar, deduplicar e ranquear demanda, e todas param no mesmo ponto: entregam uma lista priorizada, e um humano ainda precisa transformar cada linha em trabalho. Elas não têm camada de execução porque foram feitas para times de produto cujos engenheiros estão em outro lugar. A aposta aqui é a oposta: a superfície de coleta e a superfície de execução são o mesmo objeto.

É preciso deixar o roadmap público para usar isso?

Não. Público, não listado e só por convite são três modos separados. Uma agência que mantém um quadro por cliente usa o modo só por convite, e nenhum buscador chega perto dele. Um desenvolvedor solo que quer pedidos e votos dos usuários usa o modo público. A parte de execução funciona igual nos três.

O que impede um quadro público de encher de ruído?

Nada impede o ruído de chegar, e fingir o contrário seria desonesto. O que o quadro muda é o custo de lidar com ele: quase duplicatas são sinalizadas no envio, os votos dizem o que as pessoas realmente querem, e um ticket que você não vai fazer é fechado com um motivo que chega até quem escreveu. Os tickets que você mantém chegam com o contexto que um desconhecido já escreveu para você.