Um agente de código consegue transformar um ticket em um pull request enquanto você toma um café. Essa velocidade cria uma pergunta mais silenciosa que as ferramentas nunca respondem por você: uma vez que o diff existe, quem é o responsável por ele? Não quem o digitou — isso o agente fez. Mas quem responde por ele entrar em produção, por ter sido a mudança certa e pelo que acontece quando quebra às 2 da manhã. A execução passou para o agente. A responsabilidade não — e não pode passar.
A confusão piora no momento em que você passa a rodar mais de um agente. Dê um bug ao Claude Code e outro ao Codex, e você agora tem dois branches, dois resumos e nenhuma resposta compartilhada para uma pergunta simples: em nome de quem cada um deles fica quando forem integrados? Responsabilidade que vive no histórico de rolagem de um terminal não é responsabilidade. É um palpite que sobrevive até o próximo git log.
É em torno desse problema que o Sharkly foi construído. O Sharkly fica acima dos seus agentes de código como a camada que registra quem atribuiu o trabalho, qual agente o executou, quem revisa o resultado e quem o aceita. Este artigo apresenta esse modelo operacional na forma de quatro papéis e um conjunto de status, e depois percorre um ticket desde a atribuição até um PR mesclado. Para entender a mecânica de revisão por trás disso, nosso guia sobre agentes de código com human-in-the-loop cobre os cinco portões que garantem essas decisões.
TL;DR
A responsabilidade humana sobre o trabalho de agentes significa que a responsabilização por uma mudança nunca é transferida ao agente, mesmo quando a execução é. O modelo operacional tem quatro papéis: uma pessoa atribui, um Agente executa, um humano nomeado revisa e esse mesmo humano aceita. Os agentes podem levar uma Tarefa até Pronto para revisão; só uma pessoa a move para Concluído. Agentes pesquisam, executam, testam e reportam. Pessoas definem a direção, concedem autoridade e aceitam o resultado.
Quem é o responsável pelo trabalho que um agente produz
Responsabilidade e execução são dois trabalhos diferentes, e confundi-los é o erro fundamental. Execução é produzir a mudança: ler a base de código, editar arquivos, rodar testes, abrir um PR. Um agente faz isso bem e rápido. Responsabilidade é responder pelo resultado: que valia a pena fazer a mudança, que ela atende aos critérios de aceitação e que há alguém a quem se pode perguntar sobre ela daqui a três meses. Essa responsabilização permanece com uma pessoa, porque não se pode pedir a um agente que justifique uma decisão depois do fato nem que arque com a consequência.
A forma mais clara de enunciar essa divisão é o contrato humano-agente: agentes pesquisam, executam, testam e reportam; pessoas definem a direção, concedem autoridade e aceitam o resultado. A automação para onde o julgamento da equipe é necessário. Tudo até "aceitar o resultado" pode ser entregue a um agente. A aceitação em si, não — e a decisão de liberar, tampouco. Nosso artigo sobre assistentes de IA vs. colegas de equipe de IA traça a mesma linha a partir da direção oposta.
O modelo operacional: atribuir, executar, revisar, aceitar
Quando você separa a responsabilidade da execução, o fluxo de trabalho se divide em quatro papéis, cada um com uma única função. Nomeá-los é o que impede que cinco agentes em paralelo se transformem em cinco branches órfãos.
| Etapa | Quem age | Pelo que é responsável |
|---|---|---|
| Atribuir | Uma pessoa | Decidir que vale a pena fazer o trabalho, escrever os critérios de aceitação e definir quem é o responsável |
| Executar | Um Agente, por meio de um Runtime em um Computador | Produzir a mudança, rodar testes e reportar o que fez e o que está incerto |
| Revisar | O Responsável humano | Julgar o resultado com base nos critérios de aceitação e nas evidências |
| Aceitar | O mesmo Responsável humano | A decisão de mesclar e liberar |
O detalhe importante está na primeira e na última linha: a mesma pessoa é responsável pela atribuição e pela aceitação. É assim que o ciclo se fecha. Quem decidiu que o trabalho importava é quem confirma que ele foi feito. O Sharkly dá suporte a isso mantendo dois campos de atribuição em uma Tarefa ao mesmo tempo — um Responsável humano e um responsável Agente — para que responsabilidade e execução sejam registradas como fatos separados, e não como um único "atribuído a" ambíguo. Para saber como o trabalho chega ao agente, consulte nosso guia sobre atribuir, acompanhar e revisar o trabalho de agentes em um só lugar.
Status e portões: os agentes chegam a Pronto para revisão, as pessoas movem o trabalho para Concluído
O modelo operacional se torna real quando se mapeia nos status da Tarefa, porque uma mudança de status é uma decisão que você pode apontar depois. Aqui a regra é estrita e vale enunciar com clareza: os agentes podem avançar o trabalho até Pronto para revisão; só uma pessoa move uma Tarefa para Concluído.
| Categoria de status | Quem o move | Significado |
|---|---|---|
| Backlog | Pessoa | Não iniciado. Atribuir um Agente aqui não executa nada |
| Pronto para trabalho | Pessoa | Mover uma Tarefa para esta categoria é o que inicia a execução do Agente |
| Em andamento | Agente | A execução está ocorrendo em um worktree isolado |
| Pronto para revisão | Agente | A execução terminou e está aguardando o humano nomeado |
| Concluído / Aceito | Pessoa | Uma pessoa leu as evidências e aceitou o resultado |
Duas fronteiras protegem isso. Primeiro, um Agente não pode selecionar um status que seu Fluxo de Trabalho da Tarefa não lhe concede, então ele não pode marcar o próprio trabalho como aceito. Ele deixa a Tarefa aguardando revisão humana, e esse sinal chega à Caixa de Entrada da pessoa responsável, em vez de um canal que ninguém lê. Segundo, mesclar um pull request vinculado não altera o status da Tarefa. Uma mesclagem é um evento do Git, não uma decisão de aceitação, e o Sharkly os mantém separados para que "o PR foi mesclado" nunca seja confundido com "uma pessoa avaliou que isto está correto". Se a capacidade de revisão é sua preocupação, nossa análise sobre por que a revisão humana é o verdadeiro gargalo aborda como se preparar para isso.
Do ticket ao PR mesclado: um exemplo prático
Veja o modelo funcionando de ponta a ponta em uma única Tarefa, SH-312, "Adicionar limitação de taxa ao endpoint público de busca".
- Atribuir. Uma engenheira escreve a Tarefa: o endpoint, o limite desejado e os critérios de aceitação (429 em caso de estouro, os testes existentes continuam passando, um novo teste para o limite). Ela se define como a Responsável humana e escolhe o responsável Agente. A Tarefa fica em Backlog. Nada é executado ainda.
- Executar. Ela move
SH-312para um status Pronto para trabalho. Essa mudança de status inicia a execução. O Agente assume a Tarefa, prepara um worktree novo para que esse trabalho não colida com nada mais, lê a descrição e os comentários recentes, edita o endpoint, adiciona o teste e roda a suíte. - Reportar. O Agente abre um pull request e publica um comentário na Tarefa: o resumo da mudança, os testes que rodou e seus resultados, e uma observação honesta de que não fez teste de carga do limite sob tráfego real. Ele move
SH-312para Pronto para revisão. Para por aí. Não pode ir além. - Revisar. O sinal de aguardando revisão chega à Caixa de Entrada da engenheira. Ela lê na seguinte ordem: os critérios de aceitação, o comentário do Agente, o log de execução e, por fim, o diff. O log mostra por que a execução foi enfileirada e quais chamadas de ferramenta ela fez, de modo que ela revisa a mudança, e não uma narrativa sobre ela. A lacuna do teste de carga é real, então ela comenta pedindo um teste no limite documentado. Esse comentário enfileira uma execução de acompanhamento para o mesmo Agente; ela não abre uma segunda Tarefa.
- Aceitar. O Agente adiciona o teste, reporta novamente e retorna a Tarefa para Pronto para revisão. Desta vez, as evidências correspondem aos critérios. Ela mescla o PR e move
SH-312para Concluído — dois atos deliberados da pessoa que era responsável pelo trabalho desde o início.
Cada passo retorna à Tarefa: a execução, o link do PR, os comentários de revisão, a aceitação. Nada vive apenas em um terminal. Nosso guia sobre revisar código gerado por IA com evidências no nível da tarefa aprofunda o que ler antes de aceitar.
Onde a responsabilidade se rompe silenciosamente
Você não precisa de toda essa cerimônia em cada Tarefa, e fingir o contrário transforma a revisão em teatro. Use a versão leve quando o trabalho for somente leitura ou trivialmente reversível: uma auditoria de repositório ou uma atualização de dependência com testes verdes pode ir da execução direto para uma aceitação rápida. Use o ciclo completo de quatro papéis, com um humano nomeado nas duas pontas, sempre que uma mudança tocar dados, alterar uma interface pública ou não puder ser desfeita com um único comando.
O modo de falha a que se atentar não é agentes fazendo demais. É a responsabilidade ficar sem atribuição. Uma Tarefa com um responsável Agente e sem Responsável humano tem execução sem responsabilização: o problema do branch órfão disfarçado de progresso. A solução é uma regra única em todos os lugares: toda Tarefa de Agente nomeia um humano responsável por ela. Quando você estiver coordenando transferências entre vários agentes, nosso guia sobre padrões de transferência agente para agente e agente para humano mostra onde o responsável humano se situa na cadeia.
Conclusão
A responsabilidade humana sobre o trabalho de agentes não é um freio à automação. É o que torna a automação segura para escalar. Deixe os agentes fazerem a execução — toda ela — na velocidade que conseguirem. Mantenha quatro decisões com as pessoas: o que atribuir, se deve conceder a autoridade para executar, se o resultado atende ao padrão e se deve liberá-lo. Registre essas decisões como mudanças de status em uma Tarefa compartilhada, para que a responsabilização seja um fato que qualquer um pode ler, e não um palpite no histórico de rolagem de alguém.
Se você já roda vários agentes de código, o Sharkly oferece um único lugar para atribuir o trabalho deles, acompanhar a execução e registrar quem revisou e aceitou cada resultado. Você pode montar esse modelo à mão com worktrees e uma planilha, ou baixar o Sharkly e deixar que a Tarefa o sustente. Para conhecer o formato completo dessa camada, comece por gerenciamento de agentes de código acima do Claude Code e do Codex.
FAQ
A responsabilidade humana significa que uma pessoa assiste a cada execução de agente? Não. Responsabilidade é responsabilização, não supervisão. Uma pessoa atribui o trabalho e aceita o resultado; o agente executa sem supervisão nesse intervalo. De todo modo, assistir a um terminal não escala além de um agente.
Um agente pode marcar o próprio trabalho como concluído? Não. Um Agente pode avançar uma Tarefa para Pronto para revisão, mas seu Fluxo de Trabalho da Tarefa não lhe concede o status de aceito. Uma pessoa lê as evidências e move a Tarefa para Concluído.
Mesclar o pull request aceita a tarefa? Não. Mesclar um PR vinculado é um evento do Git e não altera o status da Tarefa no Sharkly. A aceitação é uma mudança de status separada, feita pelo responsável humano após a revisão.
Quem deve ser responsável pela tarefa de um agente? A pessoa que decidiu que valia a pena fazer o trabalho. O Sharkly mantém um campo de Responsável humano ao lado do responsável Agente, de modo que o sinal de revisão é encaminhado a essa pessoa, e ela aceita o resultado.
O que acontece se nenhum humano for atribuído? Você tem execução sem responsabilização. A regra segura é que toda Tarefa de Agente nomeie um responsável humano, para que uma execução concluída sempre tenha alguém que responda por ela.
