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

Um prompt descreve o ciclo; ele não consegue garanti-lo. Ele não impede que dois agentes assumam a mesma tarefa, nem consegue liberar uma tarefa presa a um agente que travou. No Weft, o claim é um lease que pertence ao servidor, então esses casos são resolvidos quer o agente tenha lembrado das instruções, quer não.

O que acontece se o meu agente travar no meio do caminho?

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

Toda tarefa concluída fica esperando a minha revisão?

Não. Por padrão, uma tarefa concluída vai direto para Done, com o resultado e as evidências. Ela para na sua Caixa de entrada para Aceitar, Retrabalhar, Depois ou Descartar só quando precisa de revisão ou quando uma verificação falha.

Por que eu ia querer que o meu agente tivesse trabalho recusado?

Porque, do contrário, ele continua produzindo coisas que você não tem tempo de conferir. Quando 5 itens (10 num time) ou cerca de 45 minutos de revisão estão esperando pelas pessoas, start_task retorna attention_queue_full e aponta ao agente o que ele ainda pode fazer. Esvaziar a fila o desbloqueia.

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

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

Blog

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

Como gerenciar tarefas de agentes de IA com um ciclo de claim que o servidor garante: leases, sinais de vida, perguntas, comprovantes e um limite para a atenção humana.

O Weft é o gerenciador de tarefas com IA para fundadores solo e pequenas equipes.

Todos os artigos

Por Andrei Finogeev · 27 de outubro de 2026

A gestão de tarefas de agentes de IA funciona quando quem manda no ciclo é o quadro, não o prompt: o agente pergunta o que fazer, assume uma tarefa com um lease que expira se ele ficar em silêncio, pergunta à pessoa só o que cabe a ela decidir e termina com um comprovante que alguém pode conferir. No Weft, cada um desses passos é uma ferramenta MCP que o servidor verifica, então um agente que pula um passo é recusado ou perde a tarefa, em vez de sair de sincronia sem ninguém perceber.

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

Colar tarefas num chat é a primeira coisa que todo mundo tenta, e funciona por uma tarde. Depois o chat acaba, e o estado acaba junto. O agente sabia qual item tinha terminado, de qual tinha desistido e sobre o que estava inseguro. Agora ninguém sabe.

Quem colou a lista vira o mensageiro: copia os resultados de volta para o quadro de verdade e refaz o trabalho que uma segunda sessão pegou porque nada dizia que ele já estava com alguém.

Dar acesso ao quadro resolve o problema da foto desatualizada, não o resto. Se as únicas ferramentas são “mover cartão” e “adicionar comentário”, o ciclo continua dependendo de o agente seguir uma convenção escrita nas instruções dele. Convenções quebram justamente quando as coisas dão errado: o agente trava no meio da execução, ou dois agentes começam no mesmo instante.

Como é o ciclo de claim como 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, então o ciclo sobrevive ao fim de qualquer chat.

get_my_work: perguntar antes de escolher. A resposta cobre o que este cliente já está segurando, o que está esperando pela pessoa, o que está atrasado ou vence em breve e se há espaço para começar alguma coisa.
start_task: assumir com um lease. O claim dura 20 minutos e move a tarefa 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 dica para não duplicar o trabalho.
report_progress: o sinal de vida. Cada chamada com o id da execução e o lease token renova o lease. Se o agente morre, os sinais param, e 20 minutos depois a execução é marcada como parada e a tarefa volta a ficar sem responsável, livre para qualquer um. Um lease perdido responde lease_lost, para que o agente saiba que o trabalho já não é dele.
request_input: só para decisões que são da pessoa. Uma pergunta de até 500 caracteres, com até 10 opções. O claim é mantido enquanto o agente espera.
complete_task: terminar com um comprovante. outcome, artifacts (evidências como uma URL, um commit ou um hash de arquivo), notDone, unknowns e nextStep.

Por que um lease e não um status? Porque o silêncio é o único sinal que um agente travado consegue mandar. Um cartão em Doing diz que alguém trabalhou nele um dia. Um lease diz que alguém está trabalhando nele agora, e para de dizer isso sozinho quando deixa de ser verdade.

O claim em si é um único insert no banco de dados, protegido por um índice único. Quando dois agentes disputam, o banco decide quem ganha, então os dois não podem ficar com a tarefa. Já dois comentários “Assumido” postados com um segundo de diferença são, os dois, comentários válidos.

Quando o agente deve 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 jurídicas, ou uma bifurcação real sem padrão razoável. Não para pedir permissão para seguir em frente.

Essa contenção importa porque uma pergunta custa à pessoa a mesma atenção que uma tarefa concluída, e no Weft ela conta para o mesmo limite. A pergunta cai na Caixa de entrada, com um push no celular e, para itens que esperam 20 minutos ou mais, um lembrete por e-mail. O Weft nunca chama o agente de volta: a resposta chega no próximo start_task ou get_my_work dele. Enquanto a pergunta está aberta, o agente mantém a tarefa por 60 minutos; depois disso o lease cai, mas a pergunta continua.

O que vai numa chamada complete_task?

Um resultado curto, evidências e um relato honesto das bordas. Aqui está 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"
}

Artefatos são coisas que a pessoa consegue conferir sem precisar acreditar na palavra do agente. notDone e unknowns não são confissões; eles separam um resultado em que você pode confiar de um que você reconstrói a partir do diff. A chamada nunca falha por falta de evidência, porque perder trabalho terminado é pior do que registrá-lo sem verificação. Mais sobre como ler esses comprovantes em o que o meu agente de IA fez.

Qual a diferença em relação a mover um cartão e postar 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 um claim, ali, é carregar a tarefa, movê-la para a seção de trabalho e postar um comentário de claim, guiado por um prompt que o time escreve nas instruções do agente. Aqui está o mesmo ciclo, passo a passo:

Passo do ciclo	Quadro só com convenção (o agente move um cartão e comenta)	O que o Weft garante, e com qual ferramenta MCP
Escolher o trabalho	O agente lista as tarefas e escolhe. Nada diz a ele que a pessoa já está soterrada de revisões.	`get_my_work` retorna o que este cliente já está segurando, 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 postar “Assumido”. Dois agentes podem fazer isso no mesmo instante e os dois acreditam que a tarefa é deles.	`start_task` pega um lease de 20 minutos numa única gravação no banco, protegida por um índice único. Quem perde recebe `already_claimed` com o id e o título da tarefa.
Continuar vivo	Comentários de progresso, se o agente lembrar. Um agente travado deixa o cartão em Doing indefinidamente.	`report_progress` renova o lease (o agente é instruído a fazer isso a cada 5 minutos). Depois de 20 minutos de silêncio, a execução é marcada como parada e a tarefa fica livre de novo.
Perguntar	Um comentário “Bloqueado:”. O agente para ou chuta; o cartão pode continuar parecendo em andamento.	`request_input` coloca uma pergunta com até 10 opções na Caixa de entrada da pessoa e mantém o claim (60 minutos enquanto estacionado). A resposta volta por `start_task` ou `get_my_work`.
Reportar	Um comentário final em texto livre. O formato depende de quão bom era o prompt.	`complete_task` recebe campos nomeados: `outcome`, `artifacts`, `notDone`, `unknowns`, `nextStep`.
Fechar ou revisar	O agente move o cartão para Review ou Done, o que o prompt tiver dito.	Por padrão a tarefa vai para Done. Ela para na Caixa de entrada para Aceitar / Retrabalhar / Depois / Descartar quando precisa de revisão ou quando uma verificação falha.
Sobrecarga	Nada. Os agentes continuam começando trabalho e a coluna Review cresce.	`start_task` recusa com `attention_queue_full` quando 5 itens (uma pessoa) ou 10 (time) esperam por pessoas, ou 45 minutos de revisão.

Para ser justo com o Hypertask: ele tem leases de verdade. A documentação lista endpoints de claim, sinal de vida e liberação de lease, e a tabela de limitações conhecidas diz que leases de tarefas, evidências e escalação 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 21 ferramentas MCP (referência das ferramentas). A CLI dele também consegue assumir tarefas, como comando opcional (changelog, referência da CLI). Então um agente com script no Hypertask consegue segurar um lease; um agente trabalhando via MCP no Claude Code ou no Cursor fica com a versão cartão-e-comentário, a menos que alguém conecte as chamadas REST.

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

O que a pessoa vê?

Na maior parte do tempo, um cartão em Done: por padrão, uma tarefa concluída vai direto para lá, com o resultado e as evidências anexados.

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

Aceitar: o trabalho fica. Se o agente passou um nextStep, a pessoa o vê acima do botão (“Se você aceitar, o agente vai …”), e aceitar aprova exatamente esse passo, nada além. A aprovação vale por 72 horas e volta ao agente por get_my_work ou start_task.
Retrabalhar: devolver, com uma observação dizendo o que está errado.
Depois: agora não. Descartar: parar de trabalhar nisso.

A Caixa de entrada fica na web, e quando algo entra nela a pessoa também recebe um push no app do Weft para celular. O acordo do nextStep impede que um agente trate “parece ok” como permissão para fazer merge, deploy e enviar: ele pode dar o único passo aprovado e depois concluir a tarefa de novo.

Por 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 em que uma pessoa revisa uma.

O Weft conta o que está esperando pelas pessoas: tarefas aguardando revisão mais perguntas abertas. Quando isso chega a 5 itens num workspace de uma pessoa, 10 num time ou cerca de 45 minutos de revisão estimada, o que vier 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. Ela informa 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 naquele cartão fica de fora, então um “merge do PR #418” aceito não é bloqueado pela fila.

Como configurar isso?

Conecte o seu cliente e entre pelo navegador; não há chave para copiar. O Weft emite refresh tokens, então o próprio cliente renova o login. No Claude Code é um 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 um app do Weft publicado em todos os planos, inclusive o Free (ChatGPT). O próprio servidor descreve o ciclo ao agente, então não é preciso nenhum prompt de ciclo de vida.

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

O que o Weft não faz aqui?

Sem CLI, API REST pública ou webhooks, então cron jobs e pipelines de CI não conseguem tocar o ciclo fora de um cliente MCP.
Sem integração com GitHub ou Slack. A evidência é o que o agente vincular em artifacts.
Sem IA embutida. 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 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 (preços).

Um bom prompt não basta para os agentes seguirem o ciclo?: Um prompt descreve o ciclo; ele não consegue garanti-lo. Ele não impede que dois agentes assumam a mesma tarefa, nem consegue liberar uma tarefa presa a um agente que travou. No Weft, o claim é um lease que pertence ao servidor, então esses casos são resolvidos quer o agente tenha lembrado das instruções, quer não.
O que acontece se o meu agente travar no meio do caminho?: Os sinais de vida param. Vinte minutos depois do último report_progress, a execução é marcada como parada, o lease token é apagado e a tarefa volta a ficar sem responsável, para que outro agente ou uma pessoa possa pegá-la. O cartão não fica uma semana parado em Doing.
Toda tarefa concluída fica esperando a minha revisão?: Não. Por padrão, uma tarefa concluída vai direto para Done, com o resultado e as evidências. Ela para na sua Caixa de entrada para Aceitar, Retrabalhar, Depois ou Descartar só quando precisa de revisão ou quando uma verificação falha.
Por que eu ia querer que o meu agente tivesse trabalho recusado?: Porque, do contrário, ele continua produzindo coisas que você não tem tempo de conferir. Quando 5 itens (10 num time) ou cerca de 45 minutos de revisão estão esperando pelas pessoas, start_task retorna attention_queue_full e aponta ao agente o que ele ainda pode fazer. Esvaziar a fila o desbloqueia.
O Hypertask também tem leases. Por que o MCP importa?: Os leases do Hypertask são endpoints REST, segundo a própria documentação (visão geral do MCP), e a CLI dele também consegue assumir tarefas. Isso serve a agentes com script. Um agente trabalhando com ferramentas MCP num editor ou num chat não tem acesso a eles ali; no Weft tem: start_task, report_progress e complete_task são ferramentas MCP.