Uma tarefa escrita para uma pessoa pode ter três palavras. "Corrigir o bug do login" funciona porque a pessoa vai perguntar o que você quis dizer. Uma tarefa escrita para um agente não pode contar com essa conversa, e a diferença aparece na forma de execuções desperdiçadas, resultados que ninguém revisa e um quadro em que a coluna de status já não significa o que as pessoas pensam.
O gerenciamento de tarefas para agentes de IA é a disciplina de escrever, atribuir e encerrar trabalho que um agente executa e uma pessoa aceita. Este guia aborda as três partes que determinam se isso se sustenta: o que uma tarefa pronta para agente contém, como a atribuição se divide entre pessoas e agentes, e como status e revisão realmente se comportam quando há execuções envolvidas. Os exemplos seguem a forma como o Sharkly implementa isso, e as mesmas regras valem para qualquer sistema que trate agentes como executores.
Resumo rápido
Uma tarefa pronta para agente declara um resultado, escopo, contexto e como a conclusão será revisada. A atribuição tem dois campos: as pessoas são responsáveis, e um agente ou equipe executa. As categorias de status comandam a execução, então um estado de backlog estacionado impede uma execução, sair dele pode iniciá-la, e os estados cancelado ou duplicado interrompem execuções ativas, enquanto concluído não o faz. O status da tarefa e o estado de execução do agente são separados, e a revisão é um estado nomeado que precisa chegar a uma pessoa, e não uma intenção que alguém resolve depois.
O que uma tarefa pronta para agente contém
A descrição é a interface. Tudo o que o agente sabe sobre a sua intenção vem dela, além do que a tarefa carrega em seus campos.
Uma tarefa útil nomeia o resultado, e não o tema, e sua descrição acrescenta o que uma pessoa ou agente novo precisaria para prosseguir:
- por que o trabalho importa;
- o que está dentro e fora do escopo;
- arquivos, links, exemplos ou comportamentos observados relevantes;
- restrições e decisões já tomadas;
- como a conclusão será revisada.
Essa última linha faz mais do que todas as outras juntas. É a diferença entre um resultado que você aceita em dois minutos e um resultado que você precisa decifrar. Comece pequeno e refine conforme o trabalho é investigado; é aceitável que a descrição de uma tarefa melhore.
Os campos carregam o restante: tipo, status, prioridade, datas, rótulos e um projeto ou sprint para dar contexto de planejamento. Uma execução montada para o agente pode incluir o título e a descrição, o status e a prioridade atuais, o contexto de espaço e sprint, comentários recentes — inclusive o comentário que a disparou —, as instruções e habilidades do agente, repositórios, ambiente e configurações de execução. Descrições rasas não são compensadas por bons modelos.
Atribuição: dois campos, não um
O erro de design mais comum no gerenciamento de tarefas para agentes é ter um único campo de responsável.
Mantenha-os separados. As pessoas são atribuídas pela responsabilidade, e um espaço pode permitir uma ou várias. Um agente ou equipe é atribuído ao campo de execução, que permanece de seleção única. Uma tarefa pode ter ambos ao mesmo tempo, e mudar o conjunto de pessoas não altera o executor, assim como atribuir um agente não substitui as pessoas.
O ganho é que nenhuma tarefa fica sob a responsabilidade de um bot. Quando um resultado exige uma decisão, há um nome associado. Quando um agente erra, a conversa de revisão tem um participante. Nosso passo a passo sobre gerenciamento de projetos com Claude Code mostra essa mesma separação em uma única tarefa, da abertura ao merge.
As equipes ocupam o mesmo campo de execução, e a execução é liderada pelo líder: o agente líder começa, lê o contexto e então envolve os membros conforme necessário. Use um único agente para trabalhos bem definidos e uma equipe quando o trabalho exigir coordenação.
Status: a parte que controla a execução
Status não é decoração quando há agentes envolvidos. Cada status visível pertence a uma categoria, e a categoria carrega um significado para o sistema.
| Categoria de status | O que significa | Efeito nas execuções do agente |
|---|---|---|
| Backlog | Estacionado, não pronto | Criar ou atribuir aqui não inicia uma execução |
| Não iniciado | Pronto, não iniciado | Mover para cá a partir do backlog pode iniciar o agente atribuído |
| Iniciado | Em andamento | As execuções prosseguem; vários status podem compartilhar esta categoria |
| Concluído | Feito, terminal | Terminal, mas não cancela uma execução já ativa |
| Cancelado | Não continuará | Interrompe execuções iniciadas para a tarefa |
| Duplicado | Representado em outro lugar | Interrompe execuções iniciadas para a tarefa |
Vale internalizar duas consequências. O backlog é uma área de preparação de verdade: prepare a tarefa, anexe o agente, e nada acontece até você movê-la. E marcar algo como concluído não é o mesmo que interrompê-lo, então cancele uma execução que você realmente quer parar.
A segunda regra é que o status do ciclo de vida e o estado de trabalho do agente são separados. Uma tarefa pode estar em um status iniciado enquanto o agente está trabalhando, aguardando resposta humana, aguardando revisão humana ou relatando um erro. Estados de execução como na fila, despachado, em execução, concluído, falhou e cancelado descrevem o progresso da execução e não movem a tarefa automaticamente. Confundir um com o outro é o que faz um quadro parecer saudável enquanto três resultados ficam sem leitura.
Revisão: tornando a passagem de bastão explícita
Os agentes encerram as execuções em um de dois lugares úteis: com um resultado ou com uma pergunta. Ambos precisam chegar a uma pessoa.
Aguardar resposta humana, aguardar revisão e trabalho falho ou bloqueado são sinais de atenção. Eles alimentam uma fila pessoal e, no Sharkly, essa é a caixa de entrada do agente, onde a pessoa responsável pode abrir a tarefa, responder em contexto, revisar o resultado ou decidir repetir ou reatribuir o trabalho.
Os comentários são a conversa duradoura na tarefa. Use-os para novo contexto, achados de revisão e decisões, e mantenha o objetivo estável e os critérios de aceitação na descrição, para que o requisito atual continue fácil de encontrar. Um comentário de um membro em uma tarefa com um agente responsável pronto pode enfileirar outra execução, e é isso que faz o feedback de revisão continuar o trabalho em vez de iniciar um segundo processo. As menções mudam isso: mencionar uma pessoa ou usar uma menção geral não inicia, por si só, uma execução do agente, e um comentário que menciona outros alvos sem o responsável suprime a execução padrão.
Antes de aceitar, leia as evidências e não apenas o diff. O log de execução mostra por que uma execução foi enfileirada, quando começou e terminou, chamadas de ferramentas e eventos de runtime, a origem do gatilho e detalhes de falha. A aceitação é uma pessoa decidindo que o resultado está correto, algo que nenhum estado de execução pode fazer por você. Baixe o Sharkly se quiser esses estados conectados entre si, em vez de montados manualmente.
Um modelo de tarefa que vale copiar
As equipes que escrevem bem tarefas para agentes costumam convergir para o mesmo esqueleto. Guarde-o em um snippet e preencha; o processo todo leva cerca de três minutos e evita uma execução desperdiçada.
Resultado: <o que é verdade quando isto estiver pronto>
Contexto:
- Por que isto importa agora
- Comportamento observado, com o erro exato ou os passos de reprodução
- Arquivos, links ou exemplos relevantes
Escopo:
- Dentro: <a mudança que você quer>
- Fora: <trabalho adjacente que o agente não deve tocar>
Restrições:
- Decisões já tomadas, convenções a seguir, coisas que não devem mudar
Revisão:
- Como a conclusão será verificada, e por quem
A linha de fora de escopo é a que se paga mais rápido. Agentes que recebem um objetivo estreito e nenhum limite tendem a melhorar coisas que você não pediu, e cada uma dessas melhorias custa tempo de revisão. Nomear o que deve ficar intocado é mais barato do que revisar o que ele tocou.
Cinco erros que vale evitar
- Um único campo de responsável. Responsabilidade e execução se fundem, e a propriedade desaparece.
- Tratar uma execução concluída como um resultado concluído. A execução terminar não diz nada sobre se a mudança estava certa.
- Repetir execuções falhas por reflexo. Abra o log primeiro. Erros de fornecedor parecidos muitas vezes exigem correções opostas.
- Deixar a revisão se acumular. Resultados de agentes não revisados são dívida que se acumula mais rápido do que pull requests não mesclados.
- Escrever tarefas para a pessoa que já sabe. Se os critérios de aceitação estão na sua cabeça, o agente está adivinhando.
Perguntas frequentes
Um agente pode mudar o status de uma tarefa? Dentro de limites. O fluxo de trabalho do tipo de tarefa restringe quais status estão disponíveis, então um agente só pode selecionar status que esse fluxo permite.
O que acontece se eu comentar enquanto uma execução está ativa? Um comentário elegível pode ser enfileirado para o próximo ciclo de execução, em vez de iniciar uma duplicata paralela, e comentários rápidos são agrupados para não criar execuções pendentes duplicadas.
Preciso de um tipo de tarefa separado para trabalho de agente? Normalmente não. Use um tipo separado quando o trabalho exigir um conjunto de campos ou um fluxo de trabalho significativamente diferente, e rótulos quando você só precisar de uma classificação leve.
Como isso difere do gerenciamento de projetos comum? As primitivas são as mesmas; o rigor não é. Nosso guia sobre gerenciamento de projetos com agentes de IA aborda o que muda em cada primitiva quando um executor não pode fazer uma pergunta de esclarecimento no corredor.
