Muitas tarefas importantes não falham enquanto alguém está trabalhando nelas. Elas falham nos intervalos.
Um fornecedor ainda não respondeu. Um relatório depende de números que chegam amanhã. Uma sessão do navegador está aberta em um computador, enquanto a pessoa que pode aprovar o próximo passo está em outro fuso horário. Quando a dependência finalmente se resolve, a conversa original já ficou soterrada e ninguém lembra exatamente onde o trabalho parou.
Um agente pessoal sempre ativo deve ser bom justamente nesses intervalos. Ele não precisa pensar sem parar nem manter um computador funcionando a toda potência. Ele precisa preservar a responsabilidade: que resultado aceitou, o que já foi feito, o que está esperando, onde estão os materiais de trabalho e que evento ou decisão permite que a tarefa continue.
Essa é a diferença entre um chat longo e um trabalho de longo prazo. Um chat longo guarda mensagens. Um trabalho de longo prazo exige um estado operacional duradouro.
O trabalho de longo prazo precisa de uma Task duradoura, não de um chat mais longo
Uma conversa é útil para estabelecer a intenção. Como unidade de responsabilidade, ela é fraca.
Suponha que você peça a um agente que prepare uma atualização para o conselho depois que o financeiro fechar o mês. O estado útil não é só o seu pedido inicial. Ele inclui o rascunho já montado, os documentos de origem conferidos, os números que faltam, a pessoa ou o sistema que deve fornecê-los, o prazo da reunião e o padrão que a atualização final precisa atingir.
No Comma, o trabalho que exige mais do que uma resposta rápida vira uma Task. Segundo a documentação de Tasks do Comma, a Task pode passar pelo trabalho em andamento, esperar em Aguardando revisão quando uma decisão humana é necessária e chegar a Concluída quando o trabalho termina. O importante não é o rótulo em si. É que a responsabilidade sobrevive depois que o chat não está mais aberto.
Uma Task duradoura deve sempre conseguir responder a seis perguntas:
Sem essas respostas, “continuo depois” é otimismo. Com elas, vira um plano.
Esperar é um estado, não uma falha
A maior parte do trabalho útil inclui esperas legítimas. O erro é tratar cada pausa como uma falha ou como um convite para ficar consultando para sempre.
Um agente deve identificar que tipo de espera começou e associar a ela uma condição de saída clara:
Essas distinções importam porque cada espera pede um comportamento diferente. Uma tarefa que espera por tempo pode dormir até o ponto de verificação. Uma que espera um evento pode vigiar uma mudança bem delimitada. Uma que espera um ambiente deve dizer qual dispositivo ou ferramenta está indisponível, em vez de tentar o trabalho em outro lugar sem avisar. Uma que espera uma decisão deve devolver uma escolha bem formulada à pessoa a quem ela pertence.
A pausa também precisa de um limite. Se a resposta esperada nunca chegar, o agente precisa de um plano alternativo: lembrar a pessoa responsável, perguntar ao usuário se deve seguir com suposições ou encerrar a Task como bloqueada. Do contrário, uma responsabilidade em segundo plano pode continuar aberta na teoria enquanto, na prática, fica abandonada.
É também por isso que sempre ativo não deve significar sempre interrompendo. A questão separada de quais eventos justificam acordar o agente, e quais deles justificam interromper o usuário, é tratada em Quando um agente pessoal sempre ativo deve acordar?. Aqui, o princípio relevante é mais estreito: toda pausa precisa de um motivo observável e de um caminho definido de volta ao trabalho.
Retome a partir de um ponto de verificação, não de um novo briefing
Quando a espera termina, o agente não deve reconstruir a tarefa a partir de mensagens espalhadas nem pedir que o usuário explique tudo de novo. Ele deve retomar a partir de um ponto de verificação.
Um ponto de verificação útil é um registro compacto da situação de trabalho:
o resultado original e o critério de conclusão atual;
a última ação significativa e o resultado dela;
os artefatos já criados ou alterados;
as suposições que continuam valendo;
o bloqueio que causou a pausa;
a próxima ação prevista quando esse bloqueio se resolver;
o ambiente em que essa ação precisa acontecer.
Isso é estado de trabalho, não memória pessoal. A memória pode ajudar um agente a lembrar as preferências de uma pessoa ao longo de muitas tarefas. Um ponto de verificação existe para que uma responsabilidade específica possa continuar com precisão depois de um tempo ociosa, de um reinício ou de uma passagem de bastão.
A distinção evita duas falhas comuns. Primeiro, o agente não deve arrastar cada detalhe de uma conversa longa para cada passo futuro. Segundo, ele não deve comprimir a tarefa com tanta força que uma restrição crítica desapareça. O ponto de verificação é seletivo: preserva aquilo de que a próxima ação depende.
O sistema por trás do Comma reflete esse padrão em mais de um nível. Os Loops do Salix podem salvar pontos de verificação do próprio estado, para que um processo delimitado em segundo plano seja retomado depois de um reinício. Essa infraestrutura não substitui uma Task bem definida, mas ilustra a mesma regra de continuidade: a recuperação deve começar de um estado conhecido, e não de suposições.
Mantenha o trabalho no ambiente de que ele realmente precisa
O trabalho de longo prazo raramente acontece em um “espaço de trabalho de IA” abstrato. Ele acontece no e-mail, em documentos, em ferramentas de projeto, em navegadores, em arquivos locais e em softwares especializados. Por isso, a continuidade inclui o lugar onde o trabalho está.
O Comma pode trabalhar em apps e arquivos conectados, no computador de uma pessoa ou no seu próprio computador na nuvem. A documentação do Salix explica que o armazenamento do computador na nuvem é mantido entre um uso e outro, mesmo que a máquina virtual possa hibernar quando está ociosa. Arquivos e ferramentas podem continuar onde o agente os deixou, e o computador pode acordar de novo quando a Task precisar.
Alguns trabalhos precisam ficar em um dispositivo específico. Um arquivo de design local, um aplicativo de desktop com login feito ou um ambiente de desenvolvimento pode existir só em um Mac ou computador Linux vinculado. A documentação de runtimes de agentes do Comma é explícita sobre esse limite: se o dispositivo externo designado estiver offline, o trabalho espera ou falha; o Salix não o transfere em silêncio para outra máquina.
Essa limitação é uma propriedade útil para a confiança. A migração automática pode parecer conveniente, mas pode mudar os arquivos disponíveis, as permissões, as credenciais e as condições de execução. Um agente confiável deve tornar esse limite visível:
O próximo passo precisa do Mac chamado “Studio”. Ele está offline. A Task está esperando lá; nenhum trabalho foi transferido para o computador na nuvem.
Agora o usuário sabe tanto por que o avanço parou quanto o que vai destravá-lo. O agente pode tentar de novo quando o dispositivo voltar ou perguntar se outro ambiente é aceitável. Ele não deve fingir que todos os runtimes são intercambiáveis.
Devolva só a decisão que pertence à pessoa
Passar o controle para uma pessoa não é uma falha de autonomia. É assim que um agente pessoal preserva a diferença entre fazer o trabalho e responder pelas consequências.
O agente deve continuar as etapas de rotina e reversíveis que fazem parte da tarefa. Ele deve devolver o controle quando chega a uma ambiguidade relevante, a um limite de permissão, a uma ação externa irreversível ou a uma escolha que depende das preferências do usuário, e não das evidências disponíveis.
A passagem de bastão em si deve ser pequena. Uma passagem ruim diz: “Estou travado, o que eu faço?” Uma útil contém:
O que mudou: a nova informação ou condição que encerrou o plano anterior.
O que já está pronto: o trabalho que o agente terminou antes de perguntar.
Que decisão resta: uma escolha precisa, e não um pedido para gerenciar de novo a Task inteira.
O que as opções mudam: a consequência relevante de cada caminho.
Quando a escolha importa: um prazo ou o efeito de esperar.
O que acontece depois: a ação que o agente vai retomar depois da resposta.
Por exemplo: “O local só consegue segurar a data até quinta-feira. Verifiquei as condições de cancelamento e preparei os dados da reserva. Aprovar agora compromete o sinal; esperar mantém a flexibilidade, mas pode fazer a gente perder a data. Envio a reserva?”
O Comma usa Aguardando revisão para o trabalho que precisa desse tipo de decisão humana. A Task continua intacta em torno da pergunta, então uma resposta pode liberar a próxima ação em vez de começar uma nova rodada de planejamento.
“Concluída” precisa de evidências e de um fechamento
Uma Task de longa duração não está concluída só porque o agente parou de agir. Ela pode ter excedido o tempo limite, esgotado a política de novas tentativas, produzido um rascunho que ainda precisa de revisão ou chegado ao fim das suas permissões.
O fechamento deve informar:
o resultado pedido;
o resultado efetivamente produzido;
os artefatos criados ou alterados;
as verificações feitas;
qualquer limitação, suposição ou pendência não resolvida;
se uma ação externa foi executada ou só preparada.
Esse registro permite que o usuário examine o trabalho sem rever toda a história dele. Também evita uma ambiguidade perigosa entre “a Task não está mais rodando” e “o resultado foi alcançado”.
Concluída é um estado do fluxo de trabalho, não um certificado de verdade. Um agente pode verificar que um arquivo foi criado, que um comando deu certo ou que uma mensagem foi enviada. Ele não pode transformar material de origem incerto em certeza mudando um status. As afirmações continuam precisando de evidências adequadas, e trabalho com consequências pode continuar merecendo revisão humana.
Um protocolo prático para trabalhos que duram dias
Você não precisa projetar um sistema de orquestração antes de delegar uma responsabilidade de vários dias. Um bom pedido consegue estabelecer o acordo essencial em poucas linhas.
Comece dizendo qual é o resultado e o que significa “bom o suficiente”. Aponte o prazo final e qualquer janela de decisão anterior. Diga quais ações o agente pode tomar sem perguntar e quais exigem aprovação. Indique o ambiente onde devem ficar o material de origem e os arquivos de trabalho.
Depois, deixe a espera explícita. Diga ao agente qual dependência é esperada, quando verificar de novo e o que fazer se ela nunca chegar. Peça que ele salve um ponto de verificação antes de cada pausa e que devolva só as decisões que realmente dependem de você. Por fim, exija uma nota de fechamento com o resultado, as verificações e a incerteza que sobrou.
Uma delegação compacta poderia ser assim:
Prepare a atualização final para o conselho depois que o financeiro publicar os números de fechamento do mês. Use o rascunho e a planilha que já estão no computador na nuvem. Você pode atualizar o rascunho e validar os totais, mas me pergunte antes de enviar qualquer coisa para fora. Se os números não tiverem chegado até terça ao meio-dia, me diga quais seções estão bloqueadas e proponha a alternativa de menor risco. Quando terminar, me devolva o documento, as fontes conferidas e as suposições que restarem.
O valor não vem de deixar o prompt elaborado. Vem de dar à Task estados claros para percorrer: aceita, em andamento, em espera, pronta para revisão, retomada e encerrada.
Perguntas frequentes
O que continua ativo enquanto uma Task de longa duração está esperando?
A Task mantém o resultado, o trabalho concluído, a dependência atual, o ponto de verificação e a condição para retomar. O ambiente de execução pode hibernar, e nenhum modelo precisa raciocinar continuamente. Se um Loop de escopo restrito estiver vigiando a condição que falta, ele continua separado do estado duradouro da Task, que diz ao agente o que fazer quando a condição chegar.
O que acontece se o computador de que uma Task precisa estiver offline?
Se a Task estiver atribuída a um runtime externo nesse dispositivo, o trabalho espera ou falha até o dispositivo ficar disponível. O Salix não o transfere automaticamente para outro computador. A Task deve deixar claros o ambiente bloqueado e a condição de recuperação.
O estado de uma Task é a mesma coisa que a memória de um agente?
Não. O estado de uma Task descreve uma responsabilidade: o resultado, o andamento, os artefatos, o bloqueio e a próxima ação. A memória pessoal pode abranger várias responsabilidades e incluir preferências duradouras. Uma Task de longa duração deve poder ser retomada sem transformar cada detalhe de trabalho em memória permanente.
Como um agente deve esperar por outra pessoa?
Ele deve registrar o que foi pedido, a quem, a partir de quando a resposta está atrasada e que alternativa se aplica. Se um evento puder ser monitorado, ele deve vigiar esse evento em vez de interromper o usuário repetidamente. Uma espera indefinida sem regra de escalonamento não é um plano completo.
O que deve ir para Aguardando revisão?
Use para decisões ou permissões que realmente pertencem ao usuário: compromissos com consequências, intenção ambígua, ações externas irreversíveis, compromissos sensíveis ou nova autoridade. O agente deve anexar o trabalho concluído e pedir a menor decisão que destrava o avanço.
Concluída significa que o resultado está correto?
Concluída significa que a Task atingiu a condição de conclusão declarada. A confiança continua dependendo da qualidade das fontes, das verificações e da revisão. Uma boa nota de conclusão separa fatos verificados, suposições e riscos não resolvidos.
A continuidade é o produto
O motivo mais forte para usar um agente pessoal sempre ativo não é que ele consegue fazer uma maratona de raciocínio sem interrupções. É que ele consegue carregar uma responsabilidade através das descontinuidades comuns do trabalho real: computadores hibernando, respostas atrasadas, dados agendados, condições que mudam e momentos em que uma pessoa precisa decidir.
Essa continuidade é construída com estado visível. A Task sabe o que deve, a espera tem um motivo, o ambiente tem nome, a passagem de bastão é delimitada e a conclusão vem com evidências. Quando essas peças sobrevivem aos intervalos, você pode deixar o trabalho sem abandoná-lo e voltar sem reconstruí-lo do zero.
