Pra mim, um agente que começa resolvendo uma tarefa específica raramente permanece nesse escopo. A demanda que chega depois da primeira versão é sempre a mesma: se o agente já lê faturas, também poderia gerar cobranças; se já gera cobranças, também poderia conciliar pagamentos. Cada extensão parece barata isoladamente, porque reutiliza o prompt existente e adiciona duas ou três ferramentas ao catálogo, sem exigir infraestrutura nova. O que não aparece no custo aparente de cada adição é o efeito acumulado: o agente passa a ter um conjunto de responsabilidades que só coexistem porque ninguém separou. É a versão agêntica da god class, com os mesmos sintomas que aparecem em código tradicional.
Na minha análise, a god class em código tradicional degrada por uma combinação conhecida. A coesão interna diminui à medida que métodos passam a operar sobre subconjuntos disjuntos do estado, enquanto o acoplamento externo aumenta porque a classe se torna dependência de cada vez mais consumidores. O resultado é que o raio de impacto de qualquer alteração cresce ao ponto em que mudanças locais produzem regressões distantes. O agente god class reproduz esses comportamentos, apenas com superfícies diferentes. A coesão do prompt cai conforme instruções sobre domínios distintos passam a competir pela mesma região do contexto, e o catálogo de ferramentas se torna a interface única pra capacidades que não têm relação entre si. O raio de impacto se manifesta como regressão comportamental: uma instrução nova, adicionada pra corrigir um caso em cobranças, altera silenciosamente o modo como o agente responde a consultas de conciliação.
O sintoma mais direto de um agente que ultrapassou o limite de responsabilidade única é a presença de instruções condicionais no system prompt que tentam rotear o próprio agente. Frases como "se a tarefa envolver emissão de documento, siga o procedimento A; se envolver consulta de status, siga o procedimento B" são sinal de que o agente está operando como despachante de subagentes que ainda não foram extraídos. O modelo executa esse roteamento interno com precisão variável, em geral alta quando as instruções são poucas e distintas, e declinante à medida que os caminhos se multiplicam e começam a compartilhar vocabulário. Em alguns pontos o roteamento falha por proximidade semântica: o agente reconhece a tarefa como próxima ao procedimento A, segue por A, e só ao final da trajetória fica claro que a tarefa pertencia a B.
A coesão do catálogo de ferramentas se comporta de forma análoga. Um catálogo coeso expõe operações que compartilham entidades e critérios de uso, o que faz com que a escolha de ferramenta seja quase determinística pra cada estado. Um catálogo incoerente expõe operações que coexistem apenas por conveniência organizacional, e a escolha passa a depender de nuances do prompt que são difíceis de manter estáveis. O efeito observado é que a taxa de tool call incorreta permanece aceitável enquanto as ferramentas novas têm semântica distante das existentes, e sobe de forma perceptível quando uma ferramenta nova compartilha nome ou descrição com uma já existente. A correção desse erro tipicamente envolve reescrever descrições de forma defensiva, o que infla o catálogo sem reduzir a ambiguidade real.
A manutenção de um agente god class segue uma trajetória previsível. Nas primeiras semanas, cada correção é pequena e local, porque o prompt ainda é legível e o catálogo ainda é navegável. Depois de alguns meses, correções passam a exigir leitura integral do prompt antes de qualquer alteração, porque a instrução nova precisa ser compatível com todas as instruções anteriores. A partir de certo ponto, as alterações passam a ser feitas por acréscimo defensivo, adicionando cláusulas de exceção que contornam a revisão da lógica central. O prompt cresce até o ponto em que cada turno paga o custo de carregar instruções que só se aplicam a uma fração das tarefas. Esse custo não é apenas financeiro: o prompt inflado reduz a janela útil pra contexto da tarefa e empurra o modelo em direção a respostas mais genéricas.
Na minha avaliação, a aplicação de Single Responsibility a agentes consiste em separar por critério de sucesso, não por contagem de ferramentas. Duas capacidades pertencem ao mesmo agente quando são avaliadas pelos mesmos critérios e operam sobre o mesmo estado, com modos de falha semelhantes. Pertencem a agentes distintos quando os critérios de sucesso divergem ou quando a evolução natural de cada capacidade segue ritmos incompatíveis com os modos de falha da outra. A heurística operacional que se sustenta é que o agente permanece coeso enquanto é possível descrever a própria responsabilidade numa frase que não contenha conjunção, e começa a perder coesão quando essa descrição precisa de "e" ou "ou" pra cobrir todos os casos que o agente atende.
O custo da separação não é trivial, e é legítimo adiar a decomposição enquanto o agente se mantém dentro de um domínio coeso. Pra mim, o erro recorrente é não reconhecer o momento em que a decomposição deixou de ser opcional. Esse momento costuma ser marcado por dois sinais que aparecem juntos: o catálogo passa a conter famílias de ferramentas que nunca são usadas juntas, e as correções passam a produzir regressões em áreas não relacionadas. Quando esses sinais coincidem com a presença de seções dedicadas a subdomínios dentro do prompt, o agente opera como agregação de agentes em regime degradado, sem a coesão que um agente único deveria apresentar, e o custo de continuar mantendo essa agregação cresce mais rápido do que o custo de separá-la.