O que fez o meu agente de IA? Quatro perguntas a responder com provas
Em cada tarefa de um agente de IA deve ver quem a fez, o que mudou, o que ficou por fazer e porquê, com provas verificáveis em vez de um comentário a dizer feito.
O Weft é o gestor de tarefas com IA para fundadores a solo e pequenas equipas.
Por Andrei Finogeev ·
Para saber o que o seu agente de IA fez, não comece pelo resumo dele. Verifique quatro coisas: que ligação fez o trabalho, o que mudou (mostrado por algo que pode abrir por si), o que ficou por fazer, e o que foi decidido e porquê. Se alguma das quatro assentar apenas na palavra do agente, tem uma narração, não um registo.
Nós fazemos o Weft. Os factos sobre outros produtos vêm das respetivas páginas oficiais, verificadas a 27 de outubro de 2026.
Porque é que um comentário a dizer "feito" não chega?
Um comentário é o agente a descrever o seu próprio trabalho. Pode até ser exato, mas o comentário não o consegue demonstrar, porque o autor é precisamente a parte que está a tentar verificar. Saber que um agente mexeu numa tarefa responde a quem. Não responde a se o trabalho é aquilo que julga que é.
O artigo do Hypertask sobre atribuição de trabalho de IA tem razão num ponto: o trabalho dos agentes deve ficar no mesmo quadro que o trabalho humano, não num registo de terminal que ninguém lê. O Hypertask também dá aos agentes identidade própria como contas de serviço, para que as escritas sejam atribuídas ao agente e não a si, e tem provas de tarefas e leases, embora a documentação dele diga que são só endpoints REST, não ferramentas MCP, por design. Onde divergimos é no que o registo deve conter. Uma sequência de comentários com o output do agente é um registo do que o agente disse. Nós queremos que o registo guarde provas.
Não há números de inquéritos neste guia. Pode testar as quatro perguntas no seu próprio quadro esta tarde, e isso diz-lhe mais do que uma média do setor.
Quais são as quatro perguntas?
Escolha qualquer tarefa que um agente tenha terminado na semana passada. Deve conseguir responder a cada uma destas perguntas em menos de um minuto, sem perguntar ao agente nem abrir a conversa dele:
- Quem a fez? Que cliente, com que ligação, assumiu e terminou a tarefa.
- O que mudou? O resultado, mais artefactos que pode verificar sem confiar no agente: um hash de commit, um URL, um ficheiro, um id de mensagem.
- O que ficou por fazer? As partes que saltou e as coisas de que não tinha a certeza.
- O que foi decidido, e porquê? Qualquer escolha feita pelo caminho, com as opções ponderadas, e todas as vezes que devolveu o trabalho.
| Pergunta | Resposta fraca: um comentário a dizer "feito" | Resposta forte: provas que pode verificar |
|---|---|---|
| Quem a fez? | "Agente", ou o seu próprio nome em todas as alterações, porque todas as ferramentas partilham uma chave | A ligação que assumiu e terminou a tarefa, com o nome que o cliente registou, e cada evento do diário marcado como pessoa ou MCP, com o id do cliente |
| O que mudou? | "Refatorei o módulo de autenticação, os testes passam" | Um hash de commit, o URL de um PR ou de uma página, um ficheiro com o seu sha256, um id de mensagem: algo que abre por si |
| O que ficou por fazer? | Nada é dito, por isso assume que nada foi saltado | Uma lista notDone ("não corri a migração em staging") e uma lista unknowns ("não tenho a certeza de que o endpoint antigo não tem outros chamadores") |
| O que foi decidido, e porquê? | Enterrado numa conversa que entretanto se perdeu lá para cima | Um registo de decisão com as opções ponderadas e a condição para a rever, mais o histórico de decisões da tarefa, incluindo porque foi devolvida |
Como sei que agente o fez?
O Weft liga-se a clientes de IA através do 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 regista que cliente a criou, e o quadro mostra o nome com que esse cliente se registou ao iniciar sessão, mais um ícone. Cada evento no diário da tarefa guarda se veio de uma pessoa ou por MCP, e que cliente o enviou.
O diário completo (get_task_history em 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 simpático, mas é exato, e distingue duas ligações mesmo quando 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 expira liberta a tarefa para outro. O guia do ciclo de assumir tarefas explica isto passo a passo, e vários agentes num só quadro trata o caso com vários clientes.
Uma regra prática: dê a cada ferramenta a sua própria ligação. Se dois clientes partilham um token de acesso, o quadro vê um só ator, e a pergunta "quem" fica sem resposta.
O que mudou, e consigo verificá-lo sem perguntar ao agente?
Quando um agente termina, chama complete_task. Só o id da tarefa é obrigatório; tudo o resto é opcional, e a chamada nunca falha por falta de provas. Isso é deliberado: perder trabalho terminado é pior do que registá-lo sem verificação. O que um comprovativo pode trazer:
- outcome: até 1000 caracteres sobre o que foi feito e onde está o resultado.
- artifacts: até 20 entradas, cada uma com um tipo (url, file, message, commit, etc.), uma localização e, opcionalmente, um digest sha256.
- claims: o que o agente afirma ter feito, guardado como afirmações e não como factos verificados.
- notDone e unknowns: tratados na secção seguinte.
- nextStep: o que o agente faria a seguir se 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 resultado continua a ser narração. Os artefactos são a parte que pode verificar. Um hash de commit existe no seu repositório ou não existe. Um URL carrega ou não carrega. O sha256 de um ficheiro coincide ou não coincide. Se um comprovativo tem resultado e nenhum artefacto, trate-o como trabalho reportado pelo agente, porque é isso que é. Na web, os cartões em Done mostram se uma tarefa está Verificada ou Segundo o agente.
O que é que o agente não fez?
É a pergunta que a maioria dos registos salta, 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 aquilo de que não tem a certeza. A própria descrição da ferramenta pede aos agentes que digam claramente o que não fizeram. É isso que separa um resultado em que pode confiar de um que tem de reconstruir.
Leia estas listas primeiro. "Não corri os testes contra a base de dados de staging" muda o que faz a seguir. Um comprovativo sem nenhuma entrada notDone numa tarefa grande merece, por si só, uma pergunta.
O que foi decidido, e porquê?
As decisões tomadas no chat desaparecem quando a conversa avança. record_decision guarda-as de duas formas:
- Um registo de decisão autónomo: um título, o resultado, o contexto, as opções realmente ponderadas, as consequências e a condição em que deve ser revista. Os registos são imutáveis; alterar um significa registar uma nova decisão que o substitui, e o antigo fica, marcado como substituído.
- A transmissão de um veredicto: quando diz a um agente na conversa "aceite", "refaz com X", "descarta" ou "agora não", ele regista esse veredicto na tarefa, com a sua nota.
get_task_history lê tudo isto em três modos: summary (o cartão, o último comprovativo e contagens), decisions (todas as decisões sobre a tarefa, incluindo porque foi devolvida, o que se mantém mesmo depois de uma aceitação posterior) e full (o diário bruto, limitado a 100 eventos). get_context entrega as decisões em vigor ao agente seguinte, dentro de um orçamento de tokens, para que a próxima execução comece do que foi decidido e não do zero. Mais sobre isto em porque se perdem as decisões tomadas em conversas com a IA.
Onde reviso, e em que clico?
Por omissão, uma tarefa concluída vai diretamente para Done. Para na sua Caixa de entrada quando precisa de revisão ou quando uma verificação falha. Aí vê o comprovativo e quatro botões: Aceitar, Retrabalhar, Depois e Descartar. Retrabalhar pede uma nota, e essa nota volta ao agente.
Se o agente indicou um nextStep, ele aparece por cima do botão Aceitar, e aceitar aprova exatamente esse passo. A aprovação é válida durante 72 horas e volta ao agente através de get_my_work ou start_task, como o único passo a dar a seguir. As perguntas que um agente faz com request_input chegam à mesma Caixa de entrada, na web e nas apps para iOS e Android, com uma notificação push.
A Caixa de entrada tem um limite de propósito: 5 itens à espera num workspace de uma pessoa, 10 numa equipa, ou 45 minutos de revisão estimada, o que chegar primeiro. Quando está cheia, start_task recusa com attention_queue_full, para que os agentes terminem ou esclareçam trabalho em vez de acumularem mais coisas para verificar.
Que provas devo pedir consoante o tipo de tarefa?
Escreva isto na descrição da tarefa, para que o agente saiba que provas espera:
- Código: o hash do commit e o URL do PR como artefactos. notDone deve indicar os testes que não correram, as migrações que não foram aplicadas e os ficheiros deixados de lado de propósito.
- Conteúdo: o URL publicado, ou o ficheiro do rascunho com o seu sha256 se ainda não estiver no ar. unknowns deve listar os factos que o agente não conseguiu confirmar.
- Pesquisa: um URL de fonte para cada afirmação importante, e o ficheiro de notas. unknowns deve separar o que uma fonte diz do que o agente deduziu.
- Contactos: o id de cada mensagem enviada, e a lista de destinatários como ficheiro. notDone deve listar quem não foi contactado e porquê.
Como controlo, à partida, o que um agente pode fazer?
A atribuição depois do facto funciona melhor com limites antes dele. No Weft, cada ligação OAuth tem um de três níveis de permissões, definido no ecrã de consentimento ou mais tarde em Definições, Clientes de IA ligados:
- total (por omissão): as 32 ferramentas.
- escrita: tudo exceto as três ferramentas destrutivas (trash_task, archive_done_tasks, complete_sprint).
- leitura: só as 11 ferramentas só de leitura.
A verificação corre em cada chamada. Desligar revoga os refresh tokens da ligação e recusa, na chamada seguinte, qualquer token emitido antes do corte. Os tokens de acesso pessoais, para clientes sem OAuth, não têm âmbitos: um token chega às 32 ferramentas, e revogá-lo tem efeito na chamada seguinte. Os agentes podem mover tarefas para uma reciclagem de 30 dias, mas não as podem eliminar de vez; restaurar da reciclagem é uma funcionalidade Pro.
O que é que o Weft não faz aqui?
- Não tem integração com GitHub nem Slack, por isso o Weft não vai procurar os seus commits ou mensagens por si. É o utilizador que abre o artefacto.
- Não tem API REST pública, webhooks nem CLI para enviar comprovativos para outros sistemas. Há uma exportação em JSON e Markdown.
- Não rastreia os passos do modelo. As ferramentas que registam prompts, tokens e latência ao nível do modelo fazem outro trabalho, e pode querer uma também.
- Os agentes escrevem os seus próprios comprovativos. O Weft torna visível a distância entre afirmação e prova; não consegue tornar um agente honesto.
Se quer agentes geridos como contas de serviço através de uma API REST, uma CLI para scripts de CI, ou funcionalidades de IA incorporadas como escrita de tarefas e triagem, o Hypertask serve-lhe melhor. A nossa página alternativa ao Hypertask compara os dois lado a lado.
- O histórico do git não chega para saber o que o meu agente fez?
- O git mostra o que mudou no código. Não mostra o que o agente saltou, aquilo de que não tinha a certeza, nem que escolha fez entre duas opções. Use o hash do commit como artefacto na tarefa e guarde o resto no comprovativo e no registo de decisão.
- Um agente não pode simplesmente inventar um artefacto?
- Pode enviar qualquer texto. A questão de um artefacto é que o pode abrir: um hash que pode procurar, um URL que pode carregar, um id de mensagem que pode encontrar. Um artefacto inventado falha no momento em que o verifica, coisa que um comentário nunca faz. Quando uma tarefa tem uma verificação e uma verificação bloqueante falha, a tarefa fica fora de Done.
- Todas as tarefas terminadas ficam à espera da minha revisão?
- Não. Por omissão, uma tarefa concluída vai para Done. Só fica à espera na sua Caixa de entrada, para Aceitar, Retrabalhar, Depois ou Descartar, quando precisa de revisão ou uma verificação falha.
- Que clientes de IA conseguem escrever comprovativos no Weft?
- Qualquer cliente MCP. O ChatGPT tem o Weft como plugin publicado em todos os planos, incluindo o Free. O Claude Code liga-se 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 o Claude Code, o ChatGPT, o Cursor e o Codex. - Quanto custa isto?
- O plano Grátis cobre 50 tarefas e 200 chamadas de IA por mês. O Pro custa 8,00 € por lugar por mês ou 67,65 € por lugar 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.