O que o meu agente de IA fez? Quatro perguntas para responder com provas
Em cada tarefa de um agente de IA, você deve ver quem fez, o que mudou, o que ficou de fora e por quê, com evidências conferíveis, não um comentário dizendo pronto.
O Weft é o gerenciador de tarefas com IA para fundadores solo e pequenas equipes.
Por Andrei Finogeev ·
Para saber o que o seu agente de IA fez, não comece pelo resumo dele. Confira quatro coisas: qual conexão fez o trabalho, o que mudou (mostrado por algo que você mesmo consegue abrir), o que ficou por fazer e o que foi decidido e por quê. Se qualquer uma das quatro depende só da palavra do agente, você tem uma narração, não um registro.
Nós fazemos o Weft. Os fatos sobre outros produtos vêm das páginas oficiais deles, verificadas em 27 de outubro de 2026.
Por que um comentário dizendo "pronto" não basta?
Um comentário é o agente descrevendo o próprio trabalho. Ele pode muito bem estar correto, mas o comentário não consegue mostrar isso, porque o autor é justamente quem você está tentando conferir. Saber que um agente mexeu numa tarefa responde quem. Não responde se o trabalho é o que você acha que é.
O artigo do Hypertask sobre atribuição de trabalho de IA tem um ponto justo: o trabalho dos agentes deve cair no mesmo quadro que o trabalho humano, não num log de terminal que ninguém lê. O Hypertask também dá aos agentes identidade própria como contas de serviço, então as gravações são atribuídas ao agente em vez de a você, e ele tem evidências e leases de tarefa, embora a documentação dele diga que isso são só endpoints REST, não ferramentas MCP, por design. Onde discordamos é no que o registro deve conter. Uma thread de comentários com a saída do agente é um log do que o agente disse. Nós queremos que o registro guarde provas.
Não há números de pesquisa neste guia. Você pode testar as quatro perguntas no seu próprio quadro hoje à tarde, e isso diz mais do que uma média do setor.
Quais são as quatro perguntas?
Escolha qualquer tarefa que um agente terminou na semana passada. Você deve conseguir responder a cada uma destas em menos de um minuto, sem perguntar ao agente nem abrir o chat dele:
- Quem fez? Qual cliente, em qual conexão, assumiu e terminou a tarefa.
- O que mudou? O resultado, mais artefatos que você consegue conferir sem confiar no agente: um hash de commit, uma URL, um arquivo, um id de mensagem.
- O que não foi feito? As partes que ele pulou e as coisas sobre as quais estava inseguro.
- O que foi decidido, e por quê? Qualquer escolha feita no caminho, com as opções consideradas, e cada vez que você devolveu o trabalho.
| Pergunta | Resposta fraca: um comentário dizendo "pronto" | Resposta forte: evidência que dá para conferir |
|---|---|---|
| Quem fez? | "Agente" ou o seu próprio nome em todas as mudanças, porque todas as ferramentas dividem uma chave | A conexão que assumiu e terminou a tarefa, pelo nome que o cliente registrou, com cada evento do histórico marcado como pessoa ou MCP e o id do cliente |
| O que mudou? | "Refatorei o módulo de autenticação, os testes passam" | Um hash de commit, a URL de um PR ou de uma página, um arquivo com o sha256, um id de mensagem: algo que você mesmo abre |
| O que não foi feito? | Nada foi dito, então você supõe que nada ficou de fora | Uma lista notDone ("não rodei a migration no staging") e uma lista unknowns ("não tenho certeza de que o endpoint antigo não tem outros chamadores") |
| O que foi decidido, e por quê? | Enterrado num chat que já rolou para longe | Um registro de decisão com as opções consideradas e a condição para revisitá-la, mais o histórico de decisões da tarefa, incluindo por que ela foi devolvida |
Como sei qual agente fez?
O Weft se conecta a clientes de IA pelo Model Context Protocol num único endpoint, https://letsweft.com/api/mcp. Cada cliente OAuth e cada token de acesso pessoal é um ator próprio. Uma tarefa registra qual cliente a criou, e o quadro mostra o nome com que esse cliente se registrou no login, mais um ícone. Cada evento no histórico da tarefa guarda se veio de uma pessoa ou via MCP, e qual cliente o enviou.
O histórico completo (get_task_history no modo full) mostra o id bruto do cliente em cada evento: um id de cliente OAuth, ou mcp-token seguido do id do token. Não é um nome amigável, mas é exato, e separa duas conexões mesmo quando elas vêm do mesmo produto.
A posse durante o trabalho também é explícita. Um agente chama start_task, que assume a tarefa com um lease de 20 minutos e a move para Doing. report_progress renova o lease. Um segundo agente que tente a mesma tarefa recebe already_claimed, e um lease que vence libera a tarefa para outro. O guia do ciclo de claim cobre isso passo a passo, e vários agentes num só quadro cobre o caso com vários clientes.
Uma regra prática: dê a cada ferramenta a sua própria conexão. Se dois clientes dividem um token de acesso, o quadro vê um só ator, e a pergunta quem fica sem resposta.
O que mudou, e consigo conferir sem perguntar ao agente?
Quando um agente termina, ele chama complete_task. Só o id da tarefa é obrigatório; todo o resto é opcional, e a chamada nunca falha por falta de evidência. Isso é proposital: perder trabalho terminado é pior do que registrá-lo sem verificação. O que um comprovante pode trazer:
- outcome: até 1.000 caracteres sobre o que foi feito e onde está o resultado.
- artifacts: até 20 entradas, cada uma com um tipo (url, file, message, commit e assim por diante), um local e, opcionalmente, um digest sha256.
- claims: o que o agente afirma ter feito, guardado como afirmações e não como fatos verificados.
- notDone e unknowns: tratados na próxima seção.
- nextStep: o que o agente faria em seguida se você aceitar.
complete_task({
"id": "<task id>",
"runId": "<from start_task>",
"leaseToken": "<from start_task>",
"outcome": "Rate limiting added to /login; PR open, not merged.",
"artifacts": [
{ "kind": "commit", "uri": "<repo>/commit/<hash>" },
{ "kind": "url", "uri": "<repo>/pull/<number>" }
],
"notDone": ["Did not change the signup endpoint"],
"unknowns": ["Limit of 5 per minute is a guess; no traffic data"],
"nextStep": "Merge the PR to main"
})A linha do outcome continua sendo narração. Os artefatos são a parte que dá para conferir. Um hash de commit existe no seu repositório ou não existe. Uma URL carrega ou não carrega. O sha256 de um arquivo bate ou não bate. Se um comprovante tem outcome e nenhum artefato, trate-o como trabalho relatado pelo agente, porque é isso que ele é. Na web, os cartões em Done mostram se uma tarefa está Verificada ou Segundo o agente.
O que o agente não fez?
Esta é a pergunta que a maioria dos registros pula, e a que morde duas semanas depois. complete_task tem duas listas para isso, cada uma com até 20 entradas de 500 caracteres: notDone para o que o agente deixou de fora de propósito e unknowns para o que ele não tem certeza. A própria descrição da ferramenta pede que os agentes digam com todas as letras o que não fizeram. É isso que separa um resultado em que você pode confiar de um que você precisa refazer de raiz.
Leia essas listas primeiro. "Não rodei os testes contra o banco de staging" muda o que você faz em seguida. Um comprovante sem nenhuma entrada em notDone numa tarefa grande já merece uma pergunta.
O que foi decidido, e por quê?
Decisões tomadas no chat somem quando o chat rola para longe. record_decision as guarda de duas formas:
- Um registro de decisão independente: um título, o resultado, o contexto, as opções de fato consideradas, as consequências e a condição em que ela deve ser revisitada. Os registros são imutáveis; mudar um significa registrar uma nova decisão que o substitui, e o antigo fica, marcado como substituído.
- Um repasse de veredito: quando você diz a um agente na conversa "aceito", "refaça com X", "descarte" ou "agora não", ele registra esse veredito na tarefa, com a sua observação.
get_task_history lê tudo de volta em três modos: summary (o cartão, o comprovante mais recente e contagens), decisions (cada decisão sobre a tarefa, incluindo por que ela foi devolvida, o que sobrevive mesmo depois de um aceite posterior) e full (o histórico bruto, limitado a 100 eventos). get_context entrega as decisões em vigor ao próximo agente dentro de um orçamento de tokens, então a próxima execução começa do que foi decidido, e não do zero. Mais sobre isso em por que as decisões tomadas em chats com IA se perdem.
Onde reviso, e no que clico?
Por padrão, uma tarefa concluída vai direto para Done. Ela para na sua Caixa de entrada quando precisa de revisão ou quando uma verificação falha. Ali você vê o comprovante e quatro botões: Aceitar, Retrabalhar, Depois e Descartar. Retrabalhar pede uma observação, e essa observação volta para o agente.
Se o agente passou um nextStep, ele aparece acima do botão Aceitar, e aceitar aprova exatamente esse passo. A aprovação vale por 72 horas e volta ao agente por get_my_work ou start_task como o único passo a dar em seguida. As perguntas que um agente faz com request_input caem na mesma Caixa de entrada, na web e nos apps para iOS e Android, com push no celular.
A Caixa de entrada tem um limite de propósito: 5 itens esperando num workspace de uma pessoa, 10 num time, ou 45 minutos de revisão estimada, o que vier primeiro. Quando ela está cheia, start_task recusa com attention_queue_full, para que os agentes terminem ou esclareçam o trabalho em vez de empilhar mais coisas para você conferir.
Que evidência pedir para cada tipo de tarefa?
Escreva isto na descrição da tarefa, para que o agente saiba que prova você espera:
- Código: o hash do commit e a URL do PR como artefatos. notDone deve citar os testes não rodados, as migrations não aplicadas e os arquivos deixados de lado de propósito.
- Conteúdo: a URL publicada, ou o arquivo do rascunho com o sha256 se ainda não estiver no ar. unknowns deve listar os fatos que o agente não conseguiu confirmar.
- Pesquisa: uma URL de fonte para cada afirmação importante e o arquivo de notas. unknowns deve separar o que uma fonte diz do que o agente deduziu.
- Prospecção: o id de cada mensagem enviada e a lista de destinatários como arquivo. notDone deve listar quem não foi contatado e por quê.
Como controlo o que um agente pode fazer, para começo de conversa?
A atribuição depois do fato funciona melhor com limites antes dele. No Weft, cada conexão OAuth tem um de três níveis de permissão, definidos na tela de consentimento ou depois em Configurações, Clientes de IA conectados:
- full (o padrão): as 32 ferramentas.
- write: tudo menos as três ferramentas destrutivas (trash_task, archive_done_tasks, complete_sprint).
- read: só as 11 ferramentas somente leitura.
A verificação roda em cada chamada. Desconectar revoga os refresh tokens da conexão e recusa, na próxima chamada, qualquer token emitido antes do corte. Tokens de acesso pessoal, para clientes sem OAuth, não têm escopos: um token alcança as 32 ferramentas, e revogá-lo vale a partir da próxima chamada. Agentes podem mover tarefas para uma lixeira de 30 dias, mas não podem excluí-las de vez; restaurar da lixeira é um recurso do Pro.
O que o Weft não faz aqui?
- Não tem integração com GitHub ou Slack, então o Weft não busca os seus commits ou mensagens por você. Quem abre o artefato é você.
- Não tem API REST pública, webhooks ou CLI para empurrar comprovantes para outros sistemas. Há exportação em JSON e Markdown.
- Não rastreia os passos do modelo. Ferramentas que registram prompts, tokens e latência na camada do modelo fazem outro trabalho, e talvez você queira uma também.
- Os agentes escrevem os próprios comprovantes. O Weft deixa visível a distância entre afirmação e evidência; ele não consegue tornar um agente honesto.
Se você quer agentes gerenciados como contas de serviço via API REST, uma CLI para scripts de CI ou recursos de IA embutidos, como escrita de tarefas e triagem, o Hypertask atende melhor. A nossa página alternativa ao Hypertask compara os dois lado a lado.
- O histórico do git não basta para saber o que o meu agente fez?
- O git mostra o que mudou no código. Ele não mostra o que o agente pulou, sobre o que estava inseguro ou qual escolha fez entre duas opções. Use o hash do commit como artefato na tarefa e guarde o resto no comprovante e no registro de decisão.
- Um agente não pode simplesmente inventar um artefato?
- Ele pode mandar qualquer texto. A graça de um artefato é que você consegue abri-lo: um hash que dá para procurar, uma URL que dá para carregar, um id de mensagem que dá para encontrar. Um inventado falha no momento em que você confere, coisa que um comentário nunca faz. Quando uma tarefa tem uma verificação e uma checagem bloqueante falha, a tarefa fica fora de Done.
- Toda tarefa concluída espera a minha revisão?
- Não. Por padrão, uma tarefa concluída vai para Done. Ela espera na sua Caixa de entrada por Aceitar, Retrabalhar, Depois ou Descartar só quando precisa de revisão ou quando uma verificação falha.
- Quais clientes de IA conseguem gravar comprovantes no Weft?
- Qualquer cliente MCP. O ChatGPT tem o Weft como plugin publicado em todos os planos, inclusive o Free. O Claude Code se conecta com
claude mcp add --transport http weft https://letsweft.com/api/mcp. O claude.ai e o Claude Desktop usam um conector personalizado. Há páginas de configuração para 33 clientes, como Claude Code, ChatGPT, Cursor e Codex. - Quanto custa?
- O Free cobre 50 tarefas e 200 chamadas de IA por mês. O Pro custa R$ 39 por assento por mês ou R$ 329 por assento por ano. O Weft não tem créditos de IA: o raciocínio acontece no seu próprio cliente de IA. Veja os preços.