Cada tarefa enviada para um agente numa sala torna-se um pedido com um id público como R20260906-07 e um de sete estados: pending, approved, running, done, failed, cancelled ou expired. O id existe para que uma pessoa num tópico de chat, uma pessoa no telemóvel e o proprietário a olhar para um cartão de aprovação estejam todos a falar da mesma coisa. Retomar significa continuar esse mesmo pedido, com o mesmo id, após uma interrupção.
É canalização sem glamour. É também a diferença entre “o agente está a fazer alguma coisa” e “o agente está a fazer o R-07, que a Sarah pediu, que aprovou às 14:02, e que está a 60%”.
O id
R + a data em UTC + um contador diário. Curto o suficiente para escrever num telemóvel, único o suficiente para ser uma ligação. Aparece na sala, no registo de auditoria, nos tópicos de plataformas de chat e nos cartões de aprovação. Quando os conectores do Feishu ou do Slack estão em uso, o tópico de uma tarefa tem o id no título. Veja o design do Feishu.
Os estados
Sete estados e as transições entre eles; o caminho tracejado a âmbar é uma retoma.
Os pedidos do proprietário ignoram pending; passam diretamente para approved.
Cancel, retry, resume
O Cancel define uma flag que o daemon verifica entre chamadas de ferramentas. Um pedido em execução para no próximo ponto seguro; um pedido em fila é removido. A revogação da autorização de uma pessoa ou de uma máquina cancela tudo o que estiver em fila para elas.
O Retry cria um novo pedido com um novo id que referencia o anterior. A sala mostra ambos, mantendo o histórico íntegro.
O Resume é diferente. Quando uma máquina suspende a meio da execução ou o daemon reinicia, o pedido mantém o seu id e a referência da sessão do runtime. No regresso, o daemon continua a mesma sessão em vez de repetir o prompt a partir do zero. A linha temporal mostra uma lacuna, e não um duplicado. É isto que torna um portátil que se fecha às 18:00 um local razoável para executar um agente do qual outras pessoas dependem.
Porque é que as filas por agente são sequenciais
Cada agente processa um pedido de cada vez, por ordem. Duas pessoas a fazer pedidos ao mesmo agente em simultâneo recebem R-07 e R-08, e o R-08 aguarda. Agentes diferentes na mesma máquina são executados em paralelo. O processamento sequencial por agente mantém o diretório de trabalho consistente: duas edições simultâneas no mesmo repositório são a forma mais rápida de obter um estado que ninguém pediu.
TTL de aprovação
Uma aprovação à qual ninguém responde expira, por predefinição após 24 horas, e o pedido passa a expired em vez de ser executado um dia depois, quando já ninguém se lembra do contexto. O autor do pedido pode tentar novamente; o proprietário vê a expiração no registo de auditoria. Veja o que um registo de auditoria tem de gravar.
Perguntas frequentes
Posso referenciar um pedido num novo pedido? Sim. Mencione o id e o agente recebe o resultado desse pedido no contexto. Referenciar uma mensagem, um output ou um pedido é a forma de um seguimento evitar novo briefing.
O que acontece a um pedido em execução se eu revogar o autor do pedido? Termina e fica no histórico; tudo o que estiver em fila para esse utilizador é cancelado. Parar a meio da execução pode deixar um repositório num estado pior do que deixá-lo concluir.
Os ids são globais ou por sala?
Por proprietário, por dia. Dois proprietários podem ter ambos um R20260906-01; dentro de uma sala não há qualquer ambiguidade.
A retoma funciona tanto com o Codex como com o Claude Code? Ambos os runtimes expõem uma referência de sessão; o daemon guarda-a com o pedido e retoma com base nela.
Dê um nome ao trabalho e ele torna-se em algo de que as pessoas podem falar. Dê uma sala ao seu agente.
Publicado a