root@construct:~/rants/assistente-proativo-objetivo$
<-- voltar para /rants
2026-05-24//OPINIAO

Agente proativo: quem mandou continuar?

Um agente proativo precisa saber quando o trabalho acabou, senão eu ganho uma assinatura de sugestões que nunca pedi. O anúncio de Gemini Spark, em maio de 2026, apresentou tarefas contínuas e assistência proativa. Gosto da proposta de deixar trabalho avançando enquanto faço outra coisa. Quero a mesma clareza pra mudar a direção e encerrar a atividade.

Em junho de 2026, pedi agentes permanentes e distribuição de trabalho pra ganhar velocidade. Depois pedi um agente acompanhando os demais e mantendo o objetivo comum. Essa sequência diz bastante sobre o que procuro no anúncio de maio, olhando agora em retrospecto: gente trabalhando em paralelo precisa continuar falando do mesmo pedido. Mesmo quando essa gente é software.

O problema aparece no acompanhamento. Pra entender onde uma tarefa parou, não quero ler todas as conversas desde o começo. Preciso saber o que já ajuda a entrega e o que ainda falta. Uma lista de comandos executados me deixa com o trabalho de reconstruir essa história. Sem essa explicação, continuo responsável por reconstruir o trabalho. Acabo virando gerente de contexto.

Considera uma pesquisa recorrente, como exemplo. O assunto perdeu prioridade, mas o assistente continua trazendo material. A execução está funcionando e a utilidade acabou. Quero atualizar o objetivo e aproveitar o que já serve sem precisar remontar a pesquisa inteira. Se não existe mais motivo pra continuar, encerrar faz parte da entrega.

Isso vale também pra coordenação que pedi. Duas execuções podem estar resolvendo a mesma dúvida. Uma pode estar esperando a outra. Quem acompanha precisa perceber a relação antes de simplesmente abrir mais trabalho. Botar outro agente pra repetir a pesquisa só aumenta a quantidade de resposta que alguém vai juntar depois.

Interrupção também tem custo. Um resultado que destrava uma decisão merece me chamar. Um detalhe intermediário pode esperar pelo resumo. Prefiro ajustar esse comportamento pelo que preciso decidir, em vez de receber notificação toda vez que o sistema demonstra estar vivo. Pra provar que está ligado, o computador já tem luz.

O que eu faço agora: defino se o pedido tem uma entrega final ou um motivo pra acompanhamento contínuo. Deixo explícito o resultado esperado e a condição de encerramento, junto de quem acompanha o andamento. Spark me interessa se ajudar a sustentar essa continuidade. Quando eu voltar, quero conseguir decidir o próximo passo sem virar arqueólogo das conversas.

Retrospectiva escrita em outubro de 2026. A data do post identifica a semana revisitada; as opiniões incorporam experiências posteriores.

Fontes: Google

The Broad Way | Kinho.dev