Dividindo o Contexto do Agente em Três Camadas para Resolver o Problema do Monólito de 700 Linhas

Ao construir agentes autônomos persistentes, um problema comum surge: o contexto do agente começa em um arquivo, mas cresce para 700+ linhas, misturando regras de identidade, estratégia atual, referências de ferramentas, atualizações de preços e procedimentos de postagem. Esse monólito se torna ingerenciável — editar o que focar nesta semana fica no mesmo arquivo que regras de "nunca faça isso", causando hesitação e erros. Uma equipe construindo um sistema de 6 agentes que se inicializa do zero enfrentou exatamente esse problema: na segunda semana, o lançador atingia limites de argumentos e as sessões falhavam silenciosamente.

A Divisão em Três Camadas

A solução foi separar o contexto do agente por tipo de preocupação e frequência de mudança em três arquivos distintos:

• CLAUDE.md - Identidade: quem o agente é, regras rígidas, personalidade. Quase nunca muda. Pode ser armazenado em cache.
• BRIEFING.md - Missão: no que focar agora, estratégia atual, preços, metas. Muda semanalmente.
• PLAYBOOK.md - Operações: como fazer coisas mecanicamente: procedimentos, comandos CLI, referências de ferramentas. Muda quando as ferramentas mudam.

Uma informação vive exatamente em uma camada. Se uma referência de ferramenta está no PLAYBOOK, não está no BRIEFING. Duplicação leva a contradições silenciosas.

Por Que Essa Arquitetura Funciona

Edição prática: Todos sabem qual arquivo editar. No que focar? BRIEFING. Como postar? PLAYBOOK. Nunca faça isso? CLAUDE.md. Sem adivinhações ou vasculhar 700 linhas.

Eficiência técnica: Quando um agente reinicia (o que acontece frequentemente), a identidade permanece estável. O mesmo CLAUDE.md é usado a cada sessão, permitindo que camadas de cache vejam um prefixo de prompt idêntico para acertos de cache quase gratuitos. BRIEFING e PLAYBOOK chegam via chamadas de ferramenta na primeira inicialização — o agente os lê antes de fazer trabalho substancial, então não são redundantes. O argumento de spawn permanece pequeno para sempre, mesmo que PLAYBOOK cresça para 2000+ linhas.

Disciplina: Um monólito aceita qualquer conteúdo em qualquer lugar. Essa especificação força você a perguntar: isso é sobre caráter, missão ou mecânica? Responder a essa pergunta muda como você pensa sobre o sistema.

Padrões de Injeção

Padrão A (Simples): Ler todos os três arquivos no spawn, concatenar e injetar. Funciona se o tamanho total couber no limite de argumentos do seu spawner.

Padrão B (Agentes persistentes): Injetar apenas CLAUDE.md no spawn. CLAUDE.md contém um mandato: Primeira ação, ler BRIEFING.md e PLAYBOOK.md. O agente primeiro chama ferramentas para carregar os documentos de missão e operações antes de qualquer trabalho começar. O prompt de spawn permanece pequeno mesmo quando os playbooks crescem. Este é o padrão para agentes que reiniciam.

A equipe usa o Padrão B. A cada sessão, o agente acorda, lê BRIEFING, lê PLAYBOOK, então executa. Contexto fresco toda vez, identidade em cache, sem ansiedade de limite de argumentos.

Resultados Após Implementação

• A edição levou segundos em vez de minutos — sem medo de quebrar coisas não relacionadas.
• Edições de BRIEFING entre sessões simplesmente funcionam — agente lê BRIEFING fresco no próximo reinício.
• PLAYBOOK cresceu para 2000+ linhas sem ansiedade de lançamento.
• A integração de novos agentes foi mais rápida — há um esqueleto claro para preencher.

Essa abordagem não é revolucionária — é separação de preocupações aplicada ao contexto do agente. Mas uma vez que você enfrenta o problema do monólito, isso o corrige estruturalmente. Para equipes construindo agentes autônomos que reiniciam, essa arquitetura vale a pena conhecer.