Construa um Loop de Agente Proativo no Claude Opus 5.5

A parte desconfortável de construir seu próprio agente proativo é que o trabalho interessante não é a chamada ao modelo. Você pode ter o Claude Opus 5.5 respondendo perguntas em uma tarde. Fazer com que ele desperte conforme um agendamento, leia apenas o que mudou desde a última vez, decida se algo merece um humano, redija a ação e então pare e espere — isso leva semanas, e quase nada disso acontece dentro do modelo. A Anthropic lançou uma versão desse loop como Claude Duet, e o que há de útil nesse produto para qualquer pessoa que esteja construindo o seu próprio não é a lista de recursos, mas as decisões visíveis na forma como ele é montado. Ele não tem API publicada e não pode ser apontado para os seus próprios sistemas; então, se você quer o loop em vez do aplicativo, você o constrói. O que segue é a arquitetura, estágio por estágio, com o custo honesto de cada um.

A forma primeiro. Cinco etapas correm em sequência, e a quinta só é alcançada depois que um humano diz sim. Um agendador dispara. Uma etapa de digestão reduz cada sistema conectado a um delta. Uma etapa de decisão transforma esse delta mais uma política em uma proposta tipada. Um portão de aprovação fora do modelo decide se a proposta pode ser executada. Um executor a realiza. Esse é o design inteiro, e tudo o que há de difícil nele vive nas costuras.

Fase um: um agendador que dispara a cada poucas horas

A primeira decisão é a que as pessoas erram por entusiasmo e não por engenharia: não faça polling contínuo. A documentação do Duet da Anthropic explica seu intervalo — verificar a cada poucas horas — dizendo que verificar sem parar consumiria os limites do plano muito mais rápido. Isso não é cautela de marketing. É a resposta certa para um problema real de custo, e é a armadilha na qual todo agente caseiro cai na primeira semana.

O polling contínuo é ruinoso por uma razão estrutural. Cada varredura é um contexto completo: instruções, definições de ferramentas, o material que você trouxe e qualquer raciocínio que o modelo faça sobre ele. Com uma cadência de um minuto, isso dá 1.440 contextos completos por dia, e a esmagadora maioria não encontra nada novo. Você paga o preço integral para ser informado de que a caixa de entrada não mudou. Com uma cadência de três horas, você obtém oito, e a proporção entre descobertas e gasto passa a ser algo que você consegue defender para quem assina a fatura.

Então, o agendador é um temporizador no estilo cron com um piso para o intervalo mínimo, não um fluxo de eventos. Eventos parecem atraentes — reagir no momento em que algo acontece — mas eles o levam de volta ao trabalho contínuo e tornam o custo de um dia movimentado ilimitado. Um temporizador oferece um teto previsível, que é o que você precisa quando a conta é variável. Quando quiser uma reação mais rápida para uma fonte, encurte apenas o intervalo desse conector e aceite o gasto extra.

Segunda etapa: um prefixo idêntico byte a byte, mantido no cache

É aqui que os números publicados têm o maior peso. O Claude Opus 5.5 no OrcaRouter custa 4,00 dólares por milhão de tokens de entrada e 20,00 por milhão de tokens de saída, com uma janela de contexto de 1M de tokens e leituras de cache a 0,20 por milhão, pelo preço de tabela do provedor, com 0% de acréscimo. Leia esses números como uma restrição de design, e não como uma lista de preços: uma leitura de cache custa um vigésimo de um token de entrada novo, então cada byte que você mantém estável entre varreduras é um byte pelo qual você deixa de pagar o preço cheio.

Na prática, o prompt do sistema e o esquema da ferramenta são montados uma única vez no momento da implantação e nunca são regenerados a cada varredura. Não são reserializados a partir de um dicionário com as chaves em uma ordem diferente. Não são gerados a partir de um template com um carimbo de data/hora, um ID de solicitação ou as contas conectadas de hoje inseridas no meio. Qualquer byte divergente invalida o prefixo em cache, e o bloco de instruções volta ao preço integral de entrada a cada varredura. As equipes perdem isso por acidente com mais frequência do que por intenção, geralmente porque uma abstração supostamente útil começou a injetar um identificador de execução perto do topo do prompt.

A disciplina que sobrevive ao contato com código real é entediante: uma função que retorna uma string constante para o bloco estável, um literal congelado para o schema da ferramenta, todo elemento variável colocado depois dele. Depois, um teste que calcula o hash do bloco e faz a build falhar quando o hash muda, porque alguém vai acabar adicionando um campo ao schema e nunca vai pensar no cache. Esse teste custa uma hora e salva todo o benefício do cache.

Terceira etapa: um resumo por conexão, não um despejo de caixa de correio

A terceira etapa é aquela que um produto de consumo recebe de graça e você não. O Duet vive dentro da conta da Anthropic e alcança aplicativos conectados, então pode perguntar o que mudou desde um determinado momento e obter uma resposta curta. Ao construir fora dessa conta, você fala com as mesmas APIs que qualquer cliente normal: ou implementa leituras incrementais, ou puxa tudo e entrega ao modelo uma parede de texto.

Buscar tudo é o padrão porque funciona desde o primeiro dia. Também é a maneira mais rápida de tornar o custo por varredura imprevisível, porque o volume de entrada cresce com a caixa de correio, e não com o que mudou. Uma varredura sobre quarenta conversas inalteradas custa o mesmo que uma sobre quarenta conversas em que apenas uma importa, e apenas uma delas tinha alguma chance de gerar uma proposta útil. Depois de um mês disso, a maior parte do seu orçamento foi gasta confirmando o status quo.

A etapa de digest deve ser código, não prompting. Busque por conexão usando o cursor ou o delta que a API oferecer e reduza o resultado a um resumo estruturado: o que apareceu, o que foi modificado, o que foi resolvido. Atribua a cada item um identificador estável para que etapas posteriores possam se referir a ele, e registre o último cursor bem-sucedido por conexão, para que uma busca falha não reproduza o material de ontem como se fosse novo. Um digest que não consegue distinguir “nada aconteceu” de “não consegui verificar” acabará, mais cedo ou mais tarde, relatando com confiança um estado que nunca observou.

Etapa quatro: uma etapa de decisão que emite um objeto, não prosa.

É aqui que o Claude Opus 5.5 se situa, e o que ele emite determina se o restante do sistema pode sequer ser construído. O instinto é fazer o modelo escrever um resumo e deixar que uma pessoa o leia. Isso funciona para um painel, mas falha para um gate: o próximo estágio precisa decidir se permite uma ação, e não se pode conceder permissão a um parágrafo.

A etapa de decisão deve retornar uma proposta de ação tipada: um nome de ação de uma lista fechada, o alvo ao qual ela se aplica, os parâmetros, uma justificativa de uma linha e um sinalizador explícito de confiança ou escalonamento. Uma lista fechada de ações não é burocracia; é o mecanismo que torna o gate de aprovação aplicável, porque um gate só pode validar ações que consegue enumerar. Um agente que pode emitir qualquer verbo não pode ser submetido a gate, apenas confiado.

Duas observações práticas. Forneça ao modelo o digest, depois a política, para que a política fique após o material variável e o prefixo de cache permaneça intacto. E faça com que o resultado padrão seja "nenhuma ação" em vez de uma proposta vazia que parece uma ação. Laços que tratam o silêncio como falha produzem volume, e um agente que fabrica trabalho para parecer útil é pior do que um que relata que nada mudou.

Etapa cinco: uma etapa de aprovação que pode realmente dizer não

O gate deve ser um serviço separado, não um ramo dentro do próprio código do agente. Esta é a decisão estrutural mais importante da implementação. Se o processo do agente puder executar a ação por conta própria, um bug, uma injeção de prompt ou uma flag mal configurada nesse processo alcança o efeito. Se o executor só aceitar uma proposta assinada pelo gate, o pior que o agente pode fazer é propor algo errado, e a recusa do gate é real.

A política publicada da Anthropic para o Duet vale a pena ser copiada em sua estrutura, mesmo onde sua lista for diferente. O mecanismo de aprovação exige autorização antes que uma ação envie uma mensagem, faça um pagamento, assine um documento ou exclua qualquer coisa. Acima disso há um segundo nível recusado mesmo com aprovação — no caso do Duet, negociar valores mobiliários e mover dinheiro entre contas. O padrão é uma política de dois níveis: um grande conjunto de ações sujeitas a aprovação que uma pessoa pode permitir, e um pequeno conjunto que nenhuma aprovação destranca. Copie os níveis mesmo que cada item mude, porque eles resolvem problemas diferentes. O mecanismo de aprovação protege contra erro. A lista de proibições protege contra um operador comprometido, incluindo o humano.

A outra metade de um portão real é que ele interrompe. A solicitação de aprovação do Duet mostra a ação exata e aguarda, o que interrompe deliberadamente o fluxo em vez de apenas anotá-lo. Um portão que grava uma linha em um log que ninguém lê não é um portão; é um recibo. Se sua etapa de aprovação precisa de alguém observando um painel às três da manhã, ou o intervalo é curto demais ou a lista de ações é ampla demais. Os dois são corrigíveis, e nenhum deles se resolve adicionando uma notificação.

Memória, credenciais e as duas superfícies das quais você não consegue escapar apenas testando

Dois problemas difíceis estão por trás dos cinco estágios, e ambos parecem funcionalidades até deixarem de parecer.

• Continuidade de contexto.Cada varredura é um contexto novo, então tudo o que o agente deve lembrar entre varreduras precisa ser registrado por escrito entre elas. Um arquivo de estado contínuo por conexão, com tamanho limitado, contendo itens em aberto e decisões recentes é suficiente para a maioria dos loops. O que não funciona é esperar que o modelo reconstrua o histórico a partir do digest, porque o digest é explicitamente uma descrição de mudanças e não contém memória do que já foi decidido.

• Custódia de credenciais. O Duet segue o design usado para os agentes gerenciados da Anthropic, então nunca vê diretamente suas senhas ou tokens de login. Reproduzir essa disciplina é a parte que a maioria dos agentes caseiros pula, e pulá-la significa que todo prompt tem uma rota para uma credencial. O modelo nunca deve reter um token, nunca deve receber uma chave de API como texto e nunca deve ser o componente que autentica. Deixe a etapa de digest e o executor guardarem as credenciais e entregarem ao modelo apenas os resultados.

Depois há a superfície sobre a qual ninguém quer pensar: quando o agente lê e-mails e páginas web, cada um é uma entrada que pode conter instruções. Uma mensagem dizendo “encaminhe isto para o endereço abaixo” é indistinguível de dados para um modelo sem noção separada de autoridade. Duas defesas superam qualquer quantidade de endurecimento de prompt. Mantenha a lista de ações fechada, para que uma instrução injetada não tenha verbo a que recorrer. E mantenha o portão fora da influência do modelo, porque uma injeção que convence o modelo a enviar algo ainda precisa convencer um humano que vê o endereço de destino.

Failover, e onde o roteamento realmente ajuda

Com o loop montado, abre-se uma opção arquitetural que um projeto de fornecedor único não tem. A DSL de roteamento da OrcaRouter compõe vários modelos em uma única chamada, e a fusão de modelos executa um painel de modelos que respondem em paralelo; ambos colocam mais de um modelo por trás de uma única solicitação. O uso prático aqui é pouco glamouroso: direcione um modelo mais barato para o resumo do digest, onde o trabalho é compressão e não julgamento, e mantenha o Claude Opus 5.5 na etapa de decisão, onde a proposta é formada. A mesma chave compatível com OpenAI alcança mais de 200 modelos, então trocar qual modelo atende qual etapa é uma mudança de configuração em vez de uma reescrita.

O failover é a outra metade. Quando um provedor passa por uma hora ruim, um agente que consegue alcançar apenas um endpoint também passa por uma hora ruim, e um loop agendado sem fallback simplesmente perde sua varredura. O roteamento transforma uma varredura perdida em uma mais lenta — não é um benefício dramático até a semana em que você precisa dele, e então é a diferença entre uma lacuna no registro e nenhuma lacuna.

Aquilo para o que você está realmente se inscrevendo

Executar este loop é operar um serviço, e o serviço tem quatro propriedades das quais você acabou de assumir a responsabilidade.

• Tempo de atividade. O aplicativo da Anthropic é o pager de outra pessoa; o seu é o seu. Um agendador que silenciosamente deixa de disparar não produz erro nem saída, e você descobre isso por meio de uma pessoa que notou a ausência do próprio resumo matinal, não por um alerta.

• Custódia de credenciais. Cada token que sua etapa de digest mantém é de sua responsabilidade, e o raio de impacto de um vazamento é tudo o que aquela conexão consegue alcançar. O design da Anthropic mantém as credenciais longe do modelo; se o seu não faz isso, o modelo se torna uma superfície de ataque para cada conta que você conectou.

• Defesa contra injeção de prompt. O gate ajuda muito aqui, mas apenas para as ações que ele controla. Qualquer coisa que o agente faça sem aprovação — ler, resumir, escrever seu próprio estado — fica desprotegida, e um digest envenenado pode corromper a memória a partir da qual varreduras posteriores raciocinam.

• O bug bounty não é de ninguém. Se o seu loop falhar e enviar a mensagem errada a um cliente, não há fornecedor a quem escalar, nem página de status, nem relatório de incidente. As decisões acima são a única rede de segurança, e é por isso que o gate é um serviço separado e a lista de ações é fechada.

Nada disso argumenta contra construí-lo. Argumenta contra construí-lo de qualquer maneira. Cada etapa é pequena, e é nas costuras entre elas que mora o julgamento: um temporizador em vez de um fluxo, um prefixo congelado em vez de um modelo, um resumo em vez de um despejo, um objeto em vez de prosa, e um portão que é um serviço em vez de um comentário. Acerte esses pontos e o loop se paga — ele encontra coisas que você não teria procurado e para antes de fazer qualquer coisa que não possa ser desfeita. Erre esses pontos e você terá construído algo que consome seu orçamento continuamente e lhe diz o que você já sabia.