Um agente pessoal sempre ativo não deve se comportar como um feed de notificações com gramática melhor. O trabalho dele não é reagir de forma visível a cada novo e-mail, issue, mudança de preço, edição de documento ou atualização da agenda. O trabalho dele é ficar de olho enquanto você está em outra coisa, reconhecer a pequena parte das mudanças que altera o que deve acontecer em seguida e trazer o trabalho certo de volta ao foco na hora certa e no nível certo.
Isso faz de “quando o agente deve acordar?” uma questão de design, e não só de desempenho. Se acordar demais, o agente vira mais uma fonte de ruído. Se ficar quieto com insistência demais, perde justamente o motivo pelo qual você pediu que ele vigiasse. Se agir sem um limite claro, um sistema útil em segundo plano vira um problema de autoridade.
A resposta certa é uma sequência de decisões. Um evento novo pode não merecer resposta nenhuma, uma revisão posterior, uma rodada do agente principal ou o seu julgamento direto. São resultados diferentes, e um agente confiável não deve juntá-los num só.
Sempre ativo deve significar continuidade, não interrupção
“Sempre ativo” tem valor porque o mundo não se organiza em sessões de chat. Uma pull request pode falhar depois que você fecha o notebook. Um fornecedor pode mudar uma data de entrega enquanto você está em reunião. Um contrato pode ser assinado três dias depois da última vez em que vocês falaram dele. O agente precisa de continuidade através dessas lacunas se vai assumir uma responsabilidade contínua.
Continuidade não exige raciocínio constante. A maioria dos eventos é duplicada, confirmação de rotina, mudança irrelevante ou informação que vai continuar útil mais tarde. Acordar um modelo grande a cada evento desperdiça processamento, mas o custo maior é de comportamento: se cada despertar vira uma mensagem, o agente gasta a atenção do usuário como se ela fosse de graça.
A pesquisa sobre notificações no trabalho encontra há muito tempo a mesma tensão. As pessoas valorizam ficar sabendo das coisas de forma passiva, mas as notificações atrapalham a tarefa em que estão concentradas. A pesquisa sobre adiamento limitado também mostra por que “agora ou nunca” é a escolha errada: um alerta pode ser adiado dentro de um limite conhecido, e assim a informação é preservada sem tratar cada chegada como urgente.
Por isso, um agente sempre ativo deve manter três relógios separados:
o momento em que um evento chega;
o momento em que o agente precisa raciocinar sobre ele;
o momento em que o usuário precisa saber ou decidir.
Às vezes os três são imediatos. Normalmente, não.
Acordar não é notificar, e notificar não é dar permissão
O limite mais importante é fácil de passar despercebido. Detectar um evento, acordar o agente principal, avisar o usuário e executar uma ação externa são quatro etapas separadas.
Suponha que o Comma esteja acompanhando uma pull request. Chega um novo comentário de revisão. O processo de vigilância pode primeiro decidir se o comentário muda algo relevante. Se mudar, o agente principal pode acordar e examinar a pull request, a discussão em volta e a Task a que ela pertence. Talvez o agente consiga atualizar um rascunho ou preparar uma correção sem interromper você. Talvez precise avisar que a janela de merge está em risco. Ou talvez chegue a uma decisão, como aceitar um compromisso de segurança, que cabe a você.
Nenhuma dessas conclusões decorre apenas da chegada do comentário.
A arquitetura do Comma foi pensada para funcionar com essa separação. Um Loop leve fica de olho e acorda o agente principal só quando necessário; depois, o agente principal faz o trabalho que depende de contexto. Os detalhes técnicos, incluindo como os Loops filtram eventos, eliminam despertares duplicados e operam dentro de cotas, estão em Loops de eventos programáveis para o nosso harness distribuído de agentes. O princípio para quem lê é mais simples: um evento é evidência, não instrução, e um despertar é um pedido para investigar, não uma permissão para agir.
Os quatro testes para acordar o agente principal
Uma boa política de despertar pode ser expressa em quatro testes. Eles não são uma tabela de pontos em que um total alto vence automaticamente. Cada teste elimina um tipo diferente de alarme falso.
1. Algo mudou de fato?
O primeiro teste é sobre estado, não sobre atividade. Uma nova mensagem é atividade. Um prazo que se antecipa, um bloqueio que aparece, uma aprovação que chega ou uma condição prometida que se cumpre é uma mudança de estado.
O agente deve ficar quieto quando o novo evento repete o que ele já sabe, só confirma o recebimento de uma mensagem sem mudar o plano ou fica fora da responsabilidade que ele foi encarregado de vigiar. Identificadores estáveis e deduplicação ajudam no nível do sistema, mas a repetição semântica ainda exige julgamento: duas mensagens diferentes podem comunicar o mesmo “nada mudou”.
Esse teste impede que movimento se passe por progresso.
2. A mudança afeta um objetivo ou uma restrição ativos?
O que é relevante depende da pessoa. Uma queda no preço de uma passagem aérea não é importante em si; importa se ficar abaixo do orçamento que o usuário definiu para uma viagem que ele ainda pretende fazer. Uma build com falha importa de jeitos diferentes em uma branch abandonada, em uma branch exploratória e em uma versão candidata.
O agente precisa do objetivo, do plano atual, das restrições pertinentes e de informação de origem suficiente para saber de onde vieram esses fatos. Sem esse contexto, “importante” tende a significar chamativo em geral, e não útil no caso específico.
É também aqui que o escopo protege a confiança. Um Loop que acompanha um repositório não deve transformar uma menção de passagem a outro projeto em uma nova tarefa. O conteúdo que chega pode informar a responsabilidade vigiada; não pode ampliá-la em silêncio.
3. Existe uma janela para agir?
Algumas mudanças importam, mas não exigem raciocínio agora. Um relatório que será revisado na sexta pode esperar em um resumo. Uma entrega atrasada talvez só se torne relevante se ameaçar um evento que depende dela. Já o cancelamento de uma reunião que libera um horário de reserva disputado, ou uma regressão em produção que se espalha para mais usuários, pode perder valor a cada minuto de atraso.
A pergunta não é apenas “isso é urgente?”. É: raciocinar agora criaria uma opção melhor do que raciocinar depois?
Se sim, acorde o agente principal. Se a informação vai continuar igualmente útil para agir, adie para um ponto de verificação natural ou agrupe com atualizações relacionadas. Se nenhuma ação é possível e nenhum plano muda, registre e fique quieto.
4. A quem cabe a próxima decisão?
Depois de reunir o contexto, o agente principal deve definir quem tem autoridade sobre o próximo passo.
Trabalho de rotina e reversível dentro das instruções do usuário muitas vezes pode continuar sem interrupção. O agente pode atualizar as anotações da Task, preparar uma comparação ou escrever o rascunho de uma resposta. Uma decisão com consequências, ambígua ou que depende de preferências deve voltar para o usuário. No Comma, o trabalho que precisa de uma decisão humana pode esperar em Aguardando revisão em vez de ser resolvido no chute ou marcado como concluído.
Uma boa escalada é específica. Ela deve dizer o que mudou, por que isso muda o plano, o que o agente já verificou, que decisão é necessária e quando essa decisão deixa de ser útil. “O que você quer fazer?” não é passagem de bastão; é análise inacabada.
Quatro resultados legítimos, não só acordar ou dormir
Depois de aplicar os testes, o agente tem quatro respostas úteis.
Ficar quieto. Nada relevante mudou, o evento é duplicado ou está fora da vigilância. O silêncio deve ser uma conclusão deliberada, com registro interno suficiente para diagnosticar erros, e não a ausência de processamento.
Adiar ou agrupar. A mudança é relevante, mas o valor dela sobrevive a um atraso. Inclua no próximo ponto de verificação da Task, em um briefing ou em um resumo compacto. O adiamento precisa de um limite: “depois” deve significar um momento ou uma condição conhecidos, e não uma pilha de pendências sem dono.
Acordar o agente principal. O evento pode mudar o plano, exige um contexto mais amplo ou é incerto demais para o filtro leve. Acordar é apropriado mesmo quando o resultado final é o silêncio; o agente principal pode investigar e concluir que nenhuma mensagem para o usuário é necessária.
Devolver o controle ao usuário. O agente chegou a uma decisão que envolve autoridade, risco, gosto ou um compromisso que só o usuário pode fazer. Ele deve preservar o trabalho já feito e apresentar a menor decisão que destrava o avanço.
Esse modelo de quatro saídas torna a incerteza administrável. Um processo de vigilância não precisa fingir confiança quando a evidência é fraca. Ele pode acordar o agente principal para uma verificação mais profunda. O agente principal, por sua vez, não precisa fabricar autonomia quando uma decisão pertence ao usuário.
A confiança deve mudar o caminho, não esconder o evento
Um sistema sempre ativo às vezes vai errar. A falha perigosa não é só um alarme falso; é um evento suprimido com toda a confiança, que o usuário nunca tem a chance de recuperar.
A postura padrão do Comma reflete essa assimetria. Quando os Loops usam o Jev para triar uma pull request, uma issue ou uma thread acompanhadas, “ficar quieto” exige alta confiança. Incertezas e erros vão para o agente principal, que tem a instrução de verificar a fonte antes de escrever para o usuário. O Jev pode classificar; não pode enviar mensagens, mudar estado externo nem se dar mais acesso. O comportamento e os limites atuais estão documentados em Conheça o Salix, o harness de agentes do Comma e na documentação dos Loops.
Esse design não elimina erros. Uma decisão de ficar quieto errada, mas tomada com confiança, ainda pode esconder uma atualização. Mas ele coloca a incerteza no caminho mais seguro: uma inspeção mais profunda em vez de um descarte silencioso. Os usuários também devem poder pausar ou excluir uma vigilância, reduzir o escopo e retomar o acesso operacional. Um agente conquista o direito de estar presente em segundo plano quando torna essa presença verificável e reversível.
Uma boa interrupção chega com o trabalho já feito
O valor de um agente pessoal sempre ativo não é perceber as coisas antes de você. Ferramentas de monitoramento já fazem isso. O valor está em ligar a mudança a uma responsabilidade ativa e reduzir o trabalho que sobra para você.
Na essência, uma interrupção útil poderia ser assim:
O revisor pediu uma mudança no fluxo de autenticação. Isso bloqueia o critério de lançamento que você definiu para quinta-feira. Verifiquei a branch atual e reproduzi o problema. Preparei um patch e testes; aprovar o compromisso de compatibilidade é a única decisão de que preciso de você antes de aplicar.
Essa mensagem traz contexto, consequência, investigação concluída, um próximo passo proposto e um limite de decisão claro. Ela não pede ao usuário que reconstrua por que o evento importa. Também não confunde uma próxima ação plausível com autorização para executá-la.
O mesmo padrão vale quando o agente decide não interromper. Uma atualização adiada deve reaparecer no ponto de verificação prometido. Uma decisão de ficar quieto deve continuar auditável. Uma Task que precisa de julgamento deve esperar de forma visível, e não sumir dentro de uma conversa sem fim.
O objetivo é uma continuidade tranquila
Um agente sempre ativo deve criar continuidade sem exigir atenção contínua. O sistema externo vigia de forma barata e restrita. O agente principal acorda quando uma mudança pode alterar o plano. Ele investiga antes de interromper. Continua o trabalho de rotina e reversível quando o usuário já deu a autoridade, e devolve as escolhas com consequências acompanhadas do trabalho pertinente.
A experiência que resulta disso não é a de um agente que fala mais. É a de um agente que consegue continuar responsável enquanto fica em silêncio, e sabe exatamente quando o silêncio deixou de ser útil.
Perguntas frequentes
O que roda antes de o agente principal acordar?
No Comma, um Loop leve vigia a caixa de entrada, o repositório, o feed, a API ou o webhook escolhidos. O programa dele pode aplicar regras determinísticas e pedir ao Jev uma decisão tipada e rápida. O agente principal e o contexto maior dele só rodam quando o Loop envia um despertar para uma investigação ou ação mais profunda.
Todo despertar do agente deve virar uma notificação para o usuário?
Não. O despertar permite que o agente principal examine o contexto e decida o que o evento muda. Ele pode continuar o trabalho em segundo plano, adiar uma atualização ou concluir que não é preciso interromper o usuário. A atenção do usuário só deve ser pedida quando estar ciente ou decidir for algo urgente.
O que deve acontecer quando o agente não tem certeza?
A incerteza deve levar o evento a quem tem mais capacidade de decidir. Um filtro leve pode acordar o agente principal; o agente principal pode verificar a fonte, reunir contexto e seguir dentro da própria autoridade ou perguntar ao usuário. A incerteza não deve virar uma decisão confiante de ficar quieto nem uma ação não autorizada.
Como um usuário pode parar uma vigilância sempre ativa?
No Comma, você pode pedir que ele pause ou exclua um Loop. O acesso aos computadores conectados também pode voltar a ser somente leitura ao desativar as operações. Uma responsabilidade sempre ativa deve ter sempre um escopo compreensível, um estado visível e um botão de desligar prático.
Transforme um sinal em um próximo passo útil
Comece com uma única fonte de eventos e anote o que mudaria de fato o seu plano, por quanto tempo a janela para agir fica aberta e que decisão precisa continuar sendo sua. Explore o Agent do Comma para ver como a atenção proativa se conecta às Tasks e à revisão, ou leia a documentação dos Loops para conhecer o modelo atual de monitoramento e seus limites.
