Estou apostando minha empresa em agentes proativos

Agentes conseguem fazer quase tudo o que você pede a eles, e esse é o problema: você ainda precisa pedir.

Vivo ouvindo gente chamar agentes de “colegas de trabalho digitais”. Esse enquadramento está errado. Um colega que fica em silêncio até você entregar uma tarefa perfeitamente delimitada, a conclui e volta a esperar não é um colega. Todo agente que você já usou funciona exatamente assim. Os modelos ficaram mais inteligentes, os harnesses ficaram melhores, as execuções ficaram mais longas, mas a interface nunca mudou: você traz o trabalho, o agente traz a mão de obra.

E a maioria das pessoas não percebeu, porque a caixa de prompt silenciosamente virou o que a IA é na nossa cabeça.

Ask anything about your stack...

Toda interface ainda é uma caixa de prompt

A caixa de entrada foi como esta era inteira começou. O ChatGPT colocou uma em cima de um modelo e virou o produto de crescimento mais rápido da história, e todos nós copiamos. Todo produto de IA desde então tem sido uma variação da mesma interação: o humano digita, a máquina responde, a máquina espera.

O Claude Code foi a evolução seguinte. O agente se mudou para o seu terminal, pegou seus arquivos, seu shell e seu histórico git, e começou a fazer trabalho de verdade em vez de falar sobre ele. Isso mudou o que os agentes conseguiam fazer, mas não como eles começam: você digita, ele trabalha, ele para e espera você digitar de novo.

~/app

$ claude

✳ 12 files · main · last session 2h ago

> fix the failing checkout tests

? for shortcuts

Depois os agentes foram para a nuvem. Codex, Devin, Claude Code na web. Eles rodam por horas em vez de minutos, abrem subagentes para paralelizar o trabalho e não morrem quando você fecha o notebook. Você entrega uma tarefa antes do almoço e volta para uma pull request.

O prompt até deixou de ser algo só de teclado. Agentes em segundo plano podem ser disparados por um alerta ou um webhook, e a maioria das plataformas de agentes agora oferece automações: quando este evento dispara, ou este cron bate, rode um agente com estas instruções.

Triage Sentry alerts Enabled

When

a Sentry alert fires

Do

investigate, open an incident if it's real

Then

post the findings to #incidents

Mas o que é uma automação? É um prompt que você escreveu com antecedência. Você previu o modo de falha, escolheu o evento e anotou o que fazer a respeito. O gatilho dispara o agente, mas o julgamento dentro dele é seu, congelado no momento da configuração. Uma automação pega exatamente o que você antecipou, e nada mais.

Você é o escalonador

Tire o ferramental e a divisão de trabalho não se moveu em três anos. O agente faz o trabalho. Decidir qual é o trabalho continua sendo tarefa sua.

Você lê os dashboards, você ouve os usuários, você descobre o que importa e comprime tudo o que aprendeu em um prompt, seja ao vivo no teclado ou com antecedência em um gatilho. O agente executa brilhantemente, mas cada pedaço de julgamento no sistema se origina em você.

A próxima evolução: agentes que encontram o trabalho

Estou apostando que a próxima evolução são agentes descobrindo sozinhos o trabalho a ser feito. Sem prompt, sem gatilho para configurar, sem instruções escritas com antecedência. Você conecta sua stack, e o agente encontra o trabalho por conta própria: ele observa os mesmos sinais que você observa, percebe o que está fora do lugar, decide se importa e começa a trabalhar nisso de forma autônoma.

Isso é fácil de dizer e brutalmente difícil de construir, porque proatividade são três problemas empilhados um sobre o outro, e pular qualquer um deles dá a você algo pior do que o agente atrás de uma caixa de entrada.

Contexto. Obviamente, o agente precisa de um modelo vivo do mundo em que opera, não de um snapshot que você colou na janela de contexto na hora do prompt. Um agente reativo com contexto ruim dá uma resposta ruim. Um agente proativo com contexto ruim derruba seu banco de produção porque achou que era staging.

Julgamento. É isso que tem me dado mais trabalho. Em qualquer momento, milhares de coisas em um sistema de produção estão levemente fora do lugar. Um agente que sinaliza todas elas é uma máquina de ruído, máquinas de ruído são silenciadas, e agentes silenciados são agentes mortos. Todo o valor da proatividade vive na distância entre “algo mudou” e “algo importa”:

[
  {
    "signal": "memory up 3% on checkout-edge",
    "verdict": "no anomaly",
    "reasoning": "within the seasonal range for this hour on this worker"
  },
  {
    "signal": "new error pattern, 2 minutes after deploy 9f3c2a1",
    "verdict": "incident",
    "reasoning": "error class never seen on this worker, tightly correlated with a deploy"
  }
]

Ação. Perceber sem agir é só um alerta mais inteligente, e alertas são a coisa que estou tentando matar. O agente precisa terminar o trabalho, dentro de limites que tornem a autonomia segura: ações reversíveis, registro de tudo e uma barreira rígida antes de qualquer coisa irreversível acontecer.

Nenhum desses três envolve o agente decidir como é o bom. Ele decide o que está fora do lugar, se importa e o que fazer a respeito, e a lista termina aí, porque em produção ninguém precisa definir o que é bom: erros em zero, latência na linha de base, filas vazias, certificados válidos. O estado desejado vem junto com o território.

O que significa que a mudança real não é de “você dá o prompt” para “o agente dá o prompt a si mesmo”. É de operação imperativa para operação declarativa. Uma automação é imperativa: você enumera os modos de falha com antecedência e escreve uma resposta para cada um. Um agente proativo é um loop de reconciliação: ele compara o sistema que você tem com o sistema que você deveria ter e trabalha para fechar a distância. O Kubernetes fez isso para infraestrutura uma década atrás, você escreve três réplicas e um controlador faz o que for preciso para manter três réplicas vivas. Ninguém fez isso para a operação do software em si. E aqui nem existe YAML para escrever, porque o estado desejado já é conhecido. Funciona logo de saída.

Comecei pela operação

Peça a um agente proativo para escolher o roadmap do seu produto e você ganha um estagiário opinativo, porque direção de produto é questão de gosto. Produção não é. É o único domínio em que os três problemas são solucionáveis hoje.

O trabalho se anuncia sozinho: taxas de erro sobem, um deploy dá errado, um certificado expira, uma fila se acumula. O trabalho já está sentado na telemetria, esperando alguém perceber. E, ao contrário dos domínios guiados por gosto, existe verdade de referência: a taxa de erro disparou ou não, o rollback restaurou a linha de base ou não, então o julgamento do agente é avaliado pelo próprio sistema, continuamente, sem espaço para impressões.

Acima de tudo, já colocamos humanos nesse trabalho. Chamamos de plantão: uma pessoa dormindo ao lado de um telefone, esperando uma máquina dizer que outra máquina está infeliz. Passei anos em observabilidade, fundei uma empresa de observabilidade que a Cloudflare adquiriu, e escrevi um manifesto inteiro sobre estruturar telemetria para que a resposta esteja a uma query de distância. A tese dele é a razão pela qual esta empresa existe: ninguém deveria estar de plantão em 2026.

Porque a verdade desconfortável sobre a última década de observabilidade é que tornamos os sistemas mais fáceis de interrogar por humanos às 3 da manhã, e então declaramos vitória enquanto os humanos continuavam sendo os acordados. Os dashboards ficaram mais bonitos e o pager continuou na mesa de cabeceira. Observabilidade sem ação é só armazenamento caro.

Como isso se parece

É isso que o Polylane faz. Aqui vai uma terça-feira concreta:

Ninguém configurou uma verificação para esse modo de falha. Não há regras para escrever nem limiares para ajustar: os agentes avaliam cada recurso conectado em um ritmo contínuo, e seus dashboards e queries salvas existentes viram a lista de verificação deles. O julgamento é onde sou mais rigoroso. O veredito padrão é nenhuma issue, porque é muito melhor deixar passar uma issue limítrofe do que acordar alguém por ruído. “Um deploy pode introduzir um bug” é verdade para todo deploy e nunca é motivo para acordar ninguém.

Quando algo é real, a investigação roda várias hipóteses concorrentes em paralelo, e o trabalho de cada agente é refutar sua hipótese em vez de confirmá-la, para que correlação nunca consiga se passar por causa. Quando a causa raiz confirmada é uma mudança de código, a correção chega como uma pull request com a investigação anexada:

Restore Hyperdrive pool size in checkout-edge

PR open coreplane/checkout-edge

Investigation report attached Checks passing

Opened by Polylane · gated on review and CI

Proativo não é sem supervisão

A autonomia está em perceber, na triagem, na arqueologia das 3 da manhã e na mitigação. Tudo o que restaura um estado conhecido como bom, o agente faz sozinho: reverter o deploy ruim, desligar a flag de volta. Essas ações são reversíveis por construção, e são elas que de fato silenciam o pager. O que continua atrás de uma barreira é qualquer coisa que crie um estado novo: uma mudança de código passa pela sua revisão e pelo seu CI, nunca por fora deles.

A linha não é humano versus agente. É reversível versus não reversível. E é por isso que você não continua secretamente de plantão: o rollback encerrou o incidente às 02:33, seis horas antes de você fazer o merge da pull request. A PR nunca foi o que estancou o sangramento. Ela é o que impede que aconteça de novo, e isso pode esperar o café.

E a barreira é sua para delegar. Agentes de revisão de código já leem cada pull request no seu repositório. Existe um mundo, não muito longe deste, em que seu agente de revisão lê a correção às 02:41, confere contra a investigação, aprova, e seu CI faz o deploy em produção antes de você acordar. Nada no loop muda, exceto quem segura o botão de aprovar. É aí que isso termina: software que se corrige sozinho, com você escrevendo a política em vez de clicar em merge.

Repare no que está faltando nesse loop:

Ask anything about your stack...

A caixa de prompt foi uma ótima forma de aprender a confiar nesses sistemas, e é uma forma péssima de operar a produção. O agente já viu cada deploy, cada linha de log e cada métrica em todos os serviços ao mesmo tempo. Mantê-lo atrás de um prompt significa que o membro mais bem informado do seu time só fala quando é chamado.

Ninguém deveria estar de plantão em 2026.