Todo engenheiro experiente carrega um modelo mental do sistema que levou meses ou anos para construir. Por que aquela tecnologia de banco de dados específica foi escolhida. Por que a API segue uma convenção para endpoints voltados ao cliente e outra para internos. Por que a lógica de retry tem parâmetros de tempo específicos. Esse conhecimento institucional é enormemente valioso e, em organizações tradicionais, vai embora quando alguém muda de cargo ou sai da empresa.
Agentes enfrentam uma versão mais aguda desse problema. Têm zero contexto acumulado. Cada sessão começa do zero. Mesmo com grandes janelas de contexto e abordagens de recuperação aumentada, a memória de trabalho do agente é uma fração do que um engenheiro veterano carrega implicitamente.
A solução ingênua ('dê ao agente toda a documentação') encontra limites práticos rápido. Contexto recuperado consome o mesmo orçamento finito de tokens que o agente precisa para seu trabalho real. E a qualidade da recuperação é irregular: às vezes o contexto certo emerge, às vezes ruído, e o agente tem capacidade limitada de distinguir entre os dois.
O Padrão de Serviço de Conhecimento
A abordagem que funciona melhor em produção é um serviço de conhecimento dedicado que outros agentes invocam por chamadas estruturadas. Quando um agente de requisitos encontra uma pergunta sem resposta ('Qual message broker este projeto usa?' ou 'Suportamos isolamento de tenant?'), não adivinha. Chama o serviço de conhecimento com uma query específica e estruturada.
O serviço pesquisa a documentação acumulada do projeto (registros de arquitetura, arquivos de convenção, logs de decisões anteriores) e retorna uma de duas respostas:
Resposta fundamentada: a documentação cobre este tema. Aqui está a informação relevante. O agente chamador prossegue com uma decisão ancorada em fato estabelecido.
Lacuna registrada: a documentação não cobre isso. O serviço registra a pergunta, o agente chamador declara a premissa que usará para prosseguir, e tanto a pergunta quanto a premissa são capturadas como dados estruturados no output.
Essa abordagem estruturada significa que cada pergunta feita e cada premissa adotada aparece como item discreto e revisável quando o pull request abre. O revisor não precisa ler nas entrelinhas do código para entender o que o agente assumiu. As premissas estão listadas explicitamente, com suas perguntas de origem, como parte do PR.
O Efeito Flywheel
É aqui que o design fica genuinamente elegante. Quando um revisor aprova um pull request, está implicitamente validando as premissas que o agente fez. Quando um revisor corrige uma premissa, essa correção flui de volta para a base de conhecimento do projeto como nova decisão documentada. Com o tempo, a base de conhecimento cresce organicamente a partir das perguntas reais que agentes encontram durante o trabalho.
Ninguém precisou sentar e escrever documentação abrangente. A documentação emergiu como consequência natural dos agentes fazendo seu trabalho e encontrando as mesmas lacunas que qualquer novo membro de equipe encontraria. Exceto que, diferente de um humano novo que absorve contexto por osmose e conversas de corredor, o processo de aprendizado do agente produz artefatos escritos que beneficiam todo futuro agente (e humano) que trabalhar no projeto.
Este artigo é de O SDLC Agêntico por Carlos Aggio.