Agente que depende de contexto alheio deveria recomendar, não agir

A promessa que mais vende agente de IA é a autonomia: o agente recebe o objetivo e age, sem ninguém no meio. Em parte dos casos ela se cumpre. Para de se cumprir no instante em que o agente decide sobre um assunto cujo contexto mora em outro lugar — em outro sistema, em outro agente, com outra pessoa.

Aí a autonomia não acelera nada. Ela pega um erro de contexto vencido e converte em ação executada, sem ninguém conferindo antes. O que seria uma frase errada num relatório vira uma ordem enviada.

Cheguei nisso planejando a arquitetura do Options_Trader, e a lição ficou com o nome de problema do agente vácuo. Ela obriga uma pergunta curta antes de qualquer decisão de design: esse agente é dono do contexto sobre o qual decide, ou está pegando emprestado?

Um agente que decide com contexto emprestado decide sobre um estado que já mudou

A definição é estreita de propósito. Agente vácuo é aquele cujo assunto de trabalho é condicional a um contexto possuído por outro agente ou por outro sistema. Ele precisa daquele dado para decidir, não é ele quem produz o dado, e não sabe a hora em que o dado muda.

Desenhado como ator autônomo, esse agente age sobre um estado que pode ter virado outro entre a leitura e a ação. Não é falha de modelo. O modelo fez o que foi pedido com a informação que tinha; quem errou foi quem deu poder de execução a quem só tinha poder de leitura.

Guardei a lição como candidata, no escopo domain:agentic_systems: ela vale no território de sistemas com agentes e ainda não virou regra geral. É um padrão recorrente em arquitetura de agentes, não uma lei de software.

Três agentes que parecem autônomos e não são donos de nada

O primeiro é um monitor de qualidade de execução, uma camada acima de um agente trader. Quem decide a execução é o trader: os fills, o slippage, o momento de mandar. O monitor observa depois que tudo já passou, e qualquer coisa que ele mexesse chegaria atrasada por construção.

O segundo é um agente de revisão de código acima de um agente que escreve código. O código muda enquanto a revisão roda. Um revisor que corrige por conta própria mexe numa versão que pode já não existir no disco. E o pior desfecho não é o conflito: é a correção silenciosa em cima de uma linha que alguém acabou de reescrever de propósito.

O terceiro é um motor de dimensionamento acima de um gerador de sinal. O tamanho da posição só faz sentido depois que o sinal existe. Agir antes dele, ou sem ele, é agir no vácuo, e é daí que vem o nome.

O padrão é o mesmo nos três. O agente de cima não é dono do dado que justifica a decisão; o dono é o agente de baixo. A distância entre os dois é onde o erro nasce.

O One_Ring não tem uma linha de código, e é justamente isso que faz ele funcionar

O One_Ring é onde essa lição ficou de pé antes de virar regra: um analista cross-projeto que lê os repositórios de vários projetos e escreve o que encontra. A pasta de código-fonte está vazia de propósito, e o README declara isso sem rodeio — o valor do repositório está nos documentos, não no código.

Na prática, alguém abre uma sessão do Claude Code e pede ao agente para ser o One_Ring. O agente lê os repositórios-alvo direto do sistema de arquivos e produz a análise em Markdown. Não existe automação em volta. É uma persona de analista que vive inteira em prompt e documento.

Toda recomendação sai de lá como item de ação com nome e dono, entregue ao agente do projeto a que ela pertence. Nenhuma é aplicada sozinha.

Isso não é limitação técnica. É a mesma lição aplicada à própria arquitetura: o One_Ring não é dono das decisões de nenhum projeto que ele lê, então não decide por eles.

Recomendar é mais lento, e é por isso mesmo que serve

Para qualquer agente que dependa de contexto alheio, meu padrão hoje é desenhar recomendador em vez de ator: ele lê, analisa e devolve uma lista de itens de ação para quem é dono do contexto aplicar. O preço é real e chato — cada rodada trava numa pessoa lendo e decidindo o que entra, não existe loop fechado, e o que chega ao fim é a lista, não a mudança feita.

Pago esse preço porque a alternativa não é "mais rápido": é trocar lentidão visível por erro silencioso. Um agente autônomo sobre contexto de outro dono não avisa que errou; ele executa, e a conta aparece depois, longe do log que explicaria o motivo.

Onde o agente é dono do contexto de ponta a ponta, a conta muda de lado: ele lê o próprio estado, decide sobre o próprio processo e age sobre o que ele mesmo mantém. Aí a autonomia é só eficiência, e a revisão humana vira burocracia.

Só dou autonomia quando o agente for dono do contexto inteiro

A regra prática cabe em uma linha: um agente age sozinho sobre um domínio quando ele mesmo é dono, de ponta a ponta, do contexto que justifica a decisão. Abaixo disso, recomendador.

Mudo de posição no dia em que o agente de cima tiver acesso ao estado completo e atualizado do agente de baixo no instante exato da decisão. Nenhum dos três casos chega perto: o monitor não sabe o que o trader vai mandar no segundo seguinte, o revisor não acompanha o editor em tempo real, o dimensionamento não enxerga um sinal que ainda não existe.

Até lá a restrição fica de pé. O One_Ring foi desenhado com ela desde o primeiro documento, e o que parece freio é o que mantém o sistema utilizável: ele nunca age em nome de quem sabe mais do que ele.