Um bom prompt não chega para os agentes seguirem o ciclo?

Um prompt descreve o ciclo; não o consegue fazer cumprir. Não impede dois agentes de assumirem a mesma tarefa, e não consegue libertar uma tarefa presa por um agente que falhou. No Weft, assumir a tarefa é um lease que pertence ao servidor, por isso esses casos ficam resolvidos quer o agente se lembre das instruções, quer não.

O que acontece se o meu agente falhar a meio?

Os sinais de vida param. Vinte minutos depois do último report_progress, a execução é marcada como inativa, o token do lease é apagado e a tarefa volta a ficar sem responsável, para que outro agente ou uma pessoa possa pegar nela. O cartão não fica uma semana parado em Doing.

Todas as tarefas terminadas ficam à espera da minha revisão?

Não. Por omissão, uma tarefa concluída vai diretamente para Done, com o resultado e as provas. Só para na sua Caixa de entrada, à espera de Aceitar, Retrabalhar, Depois ou Descartar, quando precisa de revisão ou uma verificação falha.

Porque haveria de querer que o meu agente fosse recusado?

Porque, de outro modo, continua a produzir coisas que não tem tempo para verificar. Quando há 5 itens (10 numa equipa) ou cerca de 45 minutos de revisão à espera de pessoas, start_task devolve attention_queue_full e aponta ao agente o que ainda pode fazer. Esvaziar a fila desbloqueia-o.

O Hypertask também tem leases. Porque é que o MCP importa?

Os leases do Hypertask são endpoints REST, segundo a sua própria documentação (visão geral do MCP), e a CLI também consegue assumir tarefas. Isso serve agentes em script. Um agente que trabalha com ferramentas MCP num editor ou num chat não tem acesso a eles por aí, e no Weft tem: start_task, report_progress e complete_task são ferramentas MCP.

Blogue

Gestão de tarefas de agentes de IA: o ciclo de assumir tarefas como contrato, não como prompt

Como gerir as tarefas de agentes de IA com um ciclo que o servidor faz cumprir: leases, sinais de vida, perguntas, comprovativos e um limite para a atenção humana.

O Weft é o gestor de tarefas com IA para fundadores a solo e pequenas equipas.

Todos os artigos

Por Andrei Finogeev · 27 de outubro de 2026

A gestão de tarefas de agentes de IA funciona quando é o quadro, e não o prompt, a ser dono do ciclo: o agente pergunta o que fazer, assume uma tarefa com um lease que expira se ficar em silêncio, pergunta à pessoa apenas as decisões que lhe cabem e termina com um comprovativo que alguém pode verificar. No Weft, cada um desses passos é uma ferramenta MCP que o servidor verifica, por isso um agente que salta um passo é recusado ou perde a tarefa, em vez de ir ficando dessincronizado sem ninguém dar por isso.

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 uma lista de tarefas colada no chat deixa de funcionar?

Colar tarefas numa conversa é a primeira coisa que toda a gente experimenta, e funciona durante uma tarde. Depois a conversa acaba, e o estado acaba com ela. O agente sabia que item tinha terminado, de qual tinha desistido e sobre o que tinha dúvidas. Agora ninguém sabe.

Quem colou a lista passa a ser o intermediário: copia os resultados de volta para o quadro verdadeiro e refaz trabalho que uma segunda sessão pegou porque nada dizia que já estava atribuído.

Dar acesso ao quadro resolve o problema do retrato estático, não o resto. Se as únicas ferramentas forem “mover cartão” e “adicionar comentário”, o ciclo continua a depender de o agente seguir uma convenção escrita nas instruções. As convenções falham exatamente quando as coisas correm mal: o agente falha a meio de uma execução, ou dois agentes começam no mesmo instante.

Como é o ciclo de assumir tarefas enquanto contrato?

No Weft, o ciclo tem cinco passos, e cada um é uma ferramenta separada num único endpoint MCP, https://letsweft.com/api/mcp. O servidor guarda o estado entre eles, por isso o ciclo sobrevive ao fim de qualquer conversa.

get_my_work: perguntar antes de escolher. A resposta cobre o que este cliente já tem em mãos, o que está à espera da pessoa, o que está atrasado ou tem prazo próximo e se há sequer espaço para começar alguma coisa.
start_task: assumir com um lease. A tarefa fica assumida durante 20 minutos e passa para Doing. A resposta traz um runId, um leaseToken e renewEverySeconds: 300. Um segundo cliente que tente a mesma tarefa recebe already_claimed e uma indicação para não duplicar o trabalho.
report_progress: o sinal de vida. Cada chamada com o id da execução e o token do lease renova o lease. Se o agente morrer, os sinais de vida param e, 20 minutos depois, a execução é marcada como inativa e a tarefa volta a ficar sem responsável, para quem quiser pegar nela. Um lease perdido responde lease_lost, para que o agente saiba que o trabalho já não é seu.
request_input: só para decisões que cabem à pessoa. Uma pergunta com até 500 caracteres e até 10 opções. A tarefa continua assumida enquanto o agente espera.
complete_task: terminar com um comprovativo. outcome, artifacts (provas como um URL, um commit ou um hash de ficheiro), notDone, unknowns e nextStep.

Porquê um lease e não um estado? Porque o silêncio é o único sinal que um agente que falhou consegue enviar. Um cartão em Doing diz que alguém esteve a trabalhar nele a certa altura. Um lease diz que alguém está a trabalhar nele agora, e deixa de o dizer sozinho quando isso já não é verdade.

Assumir a tarefa é uma única inserção na base de dados, protegida por um índice único. Quando dois agentes disputam a mesma tarefa, é a base de dados que decide quem ganha, por isso não a podem obter ambos. Já dois comentários “Assumida” publicados com um segundo de diferença são, os dois, comentários válidos.

Quando deve o agente chamar request_input?

Quando chega a algo que só a pessoa pode decidir: qualquer coisa irreversível, como dinheiro, publicação, produção ou questões legais, ou uma bifurcação real sem opção por omissão razoável. Não para pedir licença para continuar.

Essa contenção importa porque uma pergunta custa à pessoa a mesma atenção que uma tarefa terminada, e no Weft conta para o mesmo limite. A pergunta chega à Caixa de entrada, com uma notificação push no telemóvel e, para itens à espera há 20 minutos ou mais, um lembrete por email. O Weft nunca chama o agente de volta: a resposta chega-lhe no próximo start_task ou get_my_work. Enquanto a pergunta está aberta, o agente mantém a tarefa durante 60 minutos; depois disso o lease cai, mas a pergunta fica.

O que entra numa chamada a complete_task?

Um resultado curto, provas e um relato honesto das pontas soltas. Eis um payload realista para a correção de um bug:

{
  "id": "9b2f6c1e-4d7a-4c3b-8e21-5a0f3d9c7b14",
  "runId": "d41e8a90-2f6b-4e17-9c3a-71b5e0a4c8f2",
  "leaseToken": "lt_3f9a…",
  "outcome": "Fixed the 500 on /api/invoices when the customer has no billing address. Fix is in PR #418; the route now returns 422 with a field error.",
  "artifacts": [
    { "kind": "url", "uri": "https://github.com/acme/app/pull/418" },
    { "kind": "commit", "uri": "a1c9e07" },
    { "kind": "url", "uri": "https://preview-418.acme.dev/api/invoices/health", "httpStatus": 200 }
  ],
  "claims": [
    "Added a test for an empty billing address; the invoices test file passes locally"
  ],
  "notDone": [
    "Did not merge the PR",
    "Did not backfill the 14 invoices that failed last week"
  ],
  "unknowns": [
    "Whether the mobile app shows the 422 message or a generic error"
  ],
  "nextStep": "Merge PR #418 to main"
}

Os artefactos são coisas que a pessoa pode verificar sem ter de confiar na palavra do agente. notDone e unknowns não são confissões; separam um resultado em que se pode confiar de um que tem de reconstruir a partir do diff. A chamada nunca falha por falta de provas, porque perder trabalho terminado é pior do que registá-lo sem verificação. Mais sobre como ler estes comprovativos em o que fez o meu agente de IA.

Em que é que isto difere de mover um cartão e escrever um comentário?

O guia do Hypertask sobre o mesmo ciclo (assumir, atualizar, reportar, fechar) descreve bem o hábito. A versão MCP de assumir uma tarefa, lá, é carregar a tarefa, movê-la para a secção de trabalho e publicar um comentário a dizer que está assumida, guiado por um prompt que a equipa escreve nas instruções do agente. Eis o mesmo ciclo, passo a passo:

Passo do ciclo	Quadro só com convenções (o agente move um cartão e comenta)	O que o Weft faz cumprir, e com que ferramenta MCP
Escolher trabalho	O agente lista tarefas e escolhe. Nada lhe diz que a pessoa já está afogada em revisões.	`get_my_work` devolve o que este cliente já tem em mãos, o que espera pela pessoa, o que está atrasado e se há espaço para começar alguma coisa.
Assumir	Mover o cartão para Doing e escrever “Assumida.” Dois agentes podem fazê-lo no mesmo instante e ambos julgarem que a tarefa é sua.	`start_task` obtém um lease de 20 minutos numa única escrita na base de dados, protegida por um índice único. O que perde recebe `already_claimed` com o id e o título da tarefa.
Dar sinal de vida	Comentários de progresso, se o agente se lembrar. Um agente que falha deixa um cartão em Doing indefinidamente.	`report_progress` renova o lease (o agente é instruído a fazê-lo a cada 5 minutos). Ao fim de 20 minutos de silêncio, a execução é marcada como inativa e a tarefa fica de novo livre.
Perguntar	Um comentário “Bloqueado:”. O agente para ou adivinha; o cartão pode continuar a parecer em curso.	`request_input` coloca uma pergunta com até 10 opções na Caixa de entrada da pessoa e mantém a tarefa assumida (60 minutos enquanto espera). A resposta volta através de `start_task` ou `get_my_work`.
Reportar	Um comentário final em texto livre. A forma depende da qualidade do prompt.	`complete_task` recebe campos com nome: `outcome`, `artifacts`, `notDone`, `unknowns`, `nextStep`.
Fechar ou rever	O agente move o cartão para Review ou Done, conforme o que o prompt dizia.	Por omissão, a tarefa vai para Done. Para na Caixa de entrada, à espera de Aceitar / Retrabalhar / Depois / Descartar, quando precisa de revisão ou uma verificação falha.
Sobrecarga	Nada. Os agentes continuam a começar trabalho e a coluna Review cresce.	`start_task` recusa com `attention_queue_full` quando há 5 itens (uma pessoa) ou 10 (equipa) à espera de pessoas, ou 45 minutos de revisão.

Para ser justo com o Hypertask: tem leases reais. A documentação lista endpoints para assumir, dar sinal de vida e libertar leases, e a tabela de limitações conhecidas diz que os leases de tarefas, as provas e a escalada são só endpoints REST, por design (visão geral do MCP do Hypertask). A referência das ferramentas não tem nenhuma ferramenta de lease entre as suas 21 ferramentas MCP (referência das ferramentas). A CLI também consegue assumir tarefas, como comando opcional (changelog, referência da CLI). Assim, um agente em script no Hypertask pode ter um lease; um agente que trabalha por MCP no Claude Code ou no Cursor fica com a versão do cartão e do comentário, a menos que alguém ligue as chamadas REST.

Se os seus agentes correm como scripts e tarefas de CI, a CLI e a API REST do Hypertask são uma vantagem real, e o Weft não tem nenhuma das duas: nem CLI, nem API REST pública, nem webhooks. O Weft é para agentes que vivem dentro de um cliente MCP e precisam que o ciclo se aguente aí.

O que vê a pessoa?

Na maior parte das vezes, um cartão em Done: por omissão, uma tarefa concluída vai diretamente para lá, com o resultado e as provas anexados.

Uma tarefa para na Caixa de entrada da pessoa quando foi marcada como precisando de revisão, ou quando uma verificação falha. Aí a pessoa escolhe uma de quatro respostas:

Aceitar: o trabalho fica. Se o agente indicou um nextStep, a pessoa vê-o por cima do botão (“Se aceitar, o agente vai …”), e aceitar aprova exatamente esse passo, nada mais. A aprovação é válida durante 72 horas e volta ao agente através de get_my_work ou start_task.
Retrabalhar: devolver, com uma nota a dizer o que está mal.
Depois: agora não. Descartar: deixar de trabalhar nisto.

A Caixa de entrada está na web e, quando lá entra alguma coisa, a pessoa também recebe uma notificação push na app móvel do Weft. O acordo em torno do nextStep impede um agente de tratar um “parece bem” como licença para fazer merge, deploy e enviar: pode dar o único passo aprovado e depois concluir a tarefa outra vez.

Porque é que o agente é recusado em vez de começar mais trabalho?

Porque o recurso escasso é a atenção, não o trabalho. Um agente consegue começar dez coisas no tempo que uma pessoa demora a rever uma.

O Weft conta o que está à espera de pessoas: tarefas à espera de revisão mais perguntas em aberto. Quando isso chega a 5 itens num workspace de uma pessoa, 10 numa equipa, ou cerca de 45 minutos de revisão estimada, o que chegar primeiro, start_task recusa com attention_queue_full. O limite depende de quantas pessoas há no workspace, não do plano.

A recusa é uma instrução, não um beco sem saída. Indica o tamanho da fila, a idade do item mais antigo e as chamadas que continuam permitidas: report_progress, get_my_work, get_board_state e search. Um passo que a pessoa já aprovou nesse cartão está isento, por isso um “merge PR #418” aceite não fica bloqueado pela fila.

Como configuro isto?

Ligue o seu cliente e inicie sessão no navegador; não há nenhuma chave para copiar. O Weft emite refresh tokens, por isso o cliente renova a sessão sozinho. No Claude Code é um só comando, claude mcp add --transport http weft https://letsweft.com/api/mcp (página de configuração). O Cursor tem instalação com um clique (Cursor), o Codex precisa de uma entrada de configuração e de codex mcp login weft (Codex), e o ChatGPT tem uma app do Weft publicada em todos os planos, incluindo o Free (ChatGPT). O próprio servidor descreve o ciclo ao agente, por isso não é preciso nenhum prompt sobre o ciclo de vida.

Para um passo a passo com o Claude Code, veja um quadro de tarefas para o Claude Code. Para vários agentes num só quadro, onde os leases e already_claimed mais importam, veja vários agentes de IA, um só quadro. O protocolo em si está documentado em modelcontextprotocol.io, e outros quadros MCP são comparados em gestores de tarefas MCP.

O que é que o Weft não faz aqui?

Não tem CLI, API REST pública nem webhooks, por isso tarefas cron e pipelines de CI não conseguem conduzir o ciclo fora de um cliente MCP.
Não tem integração com GitHub nem Slack. As provas são o que o agente ligar em artifacts.
Não tem IA incorporada. O raciocínio acontece no seu próprio cliente de IA, e é também por isso que o Weft não precisa de créditos de IA.

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 (preços).

Um bom prompt não chega para os agentes seguirem o ciclo?: Um prompt descreve o ciclo; não o consegue fazer cumprir. Não impede dois agentes de assumirem a mesma tarefa, e não consegue libertar uma tarefa presa por um agente que falhou. No Weft, assumir a tarefa é um lease que pertence ao servidor, por isso esses casos ficam resolvidos quer o agente se lembre das instruções, quer não.
O que acontece se o meu agente falhar a meio?: Os sinais de vida param. Vinte minutos depois do último report_progress, a execução é marcada como inativa, o token do lease é apagado e a tarefa volta a ficar sem responsável, para que outro agente ou uma pessoa possa pegar nela. O cartão não fica uma semana parado em Doing.
Todas as tarefas terminadas ficam à espera da minha revisão?: Não. Por omissão, uma tarefa concluída vai diretamente para Done, com o resultado e as provas. Só para na sua Caixa de entrada, à espera de Aceitar, Retrabalhar, Depois ou Descartar, quando precisa de revisão ou uma verificação falha.
Porque haveria de querer que o meu agente fosse recusado?: Porque, de outro modo, continua a produzir coisas que não tem tempo para verificar. Quando há 5 itens (10 numa equipa) ou cerca de 45 minutos de revisão à espera de pessoas, start_task devolve attention_queue_full e aponta ao agente o que ainda pode fazer. Esvaziar a fila desbloqueia-o.
O Hypertask também tem leases. Porque é que o MCP importa?: Os leases do Hypertask são endpoints REST, segundo a sua própria documentação (visão geral do MCP), e a CLI também consegue assumir tarefas. Isso serve agentes em script. Um agente que trabalha com ferramentas MCP num editor ou num chat não tem acesso a eles por aí, e no Weft tem: start_task, report_progress e complete_task são ferramentas MCP.